Angenommen, ein Verein möchte eine Web-App, in der Mitglieder sich anmelden, Schichten für ein Sommerfest eintragen und Fotos hochladen. Mit Firebase wäre das in wenigen Tagen erledigt. Doch der Kassenwart will die Daten später in einer Tabellenkalkulation auswerten, die IT-Beauftragte möchte keinen Dienst, der nur bei einem einzigen Cloud-Anbieter läuft, und ein Entwickler im Team schreibt lieber SQL als Sicherheitsregeln in einer eigenen Sprache.

Für genau diese Ausgangslage ist Supabase entstanden. Die Plattform bietet die typischen Bausteine eines Backend-as-a-Service (BaaS), also Anmeldung, Datenbank, Dateiablage und Echtzeit-Updates als fertig betriebene Dienste. Im Zentrum steht aber keine eigene Datenbank, sondern PostgreSQL, eines der verbreitetsten relationalen Datenbanksysteme. Ein Hinweis zur Schreibweise: Das Produkt heißt Supabase. Die Schreibweise „Superbase“, die auch im alten Titel dieses Beitrags stand, ist falsch.

Was Supabase ist und woher es kommt

Supabase wurde 2020 von Paul Copplestone und Ant Wilson gegründet und trat ausdrücklich als Open-Source-Alternative zu Firebase an. Anders als Firebase ist Supabase kein monolithisches Produkt, sondern ein Verbund aus Open-Source-Komponenten, die um eine PostgreSQL-Datenbank herum angeordnet sind. Einige davon hat Supabase selbst entwickelt, andere sind etablierte Projekte aus der Postgres-Welt.

Jedes Supabase-Projekt ist damit im Kern eine vollwertige PostgreSQL-Datenbank. Man kann sich mit jedem gängigen Postgres-Werkzeug verbinden, Tabellen mit SQL anlegen, Erweiterungen aktivieren und die Daten jederzeit mit pg_dump exportieren. Das ist der entscheidende Unterschied zu Plattformen mit eigener Datenhaltung: Wer Supabase verlässt, nimmt eine Standarddatenbank mit.

Der Code der Plattform steht unter freizügigen Open-Source-Lizenzen, vor allem Apache 2.0 und MIT, die auch kommerzielle Nutzung und Selbstbetrieb erlauben. Daneben gibt es den gehosteten Dienst unter supabase.com, über den das Unternehmen Geld verdient.

Die Bausteine im Überblick

Ein Supabase-Projekt besteht aus mehreren Diensten, die gemeinsam ausgeliefert werden:

• Datenbank: PostgreSQL mit zahlreichen Erweiterungen, die sich bei Bedarf aktivieren lassen, darunter pgvector für Vektorsuche in KI-Anwendungen.
• Automatische APIs: PostgREST erzeugt aus dem Datenbankschema eine REST-Schnittstelle. Jede Tabelle und jede View wird ohne eigenen Servercode über HTTP lesbar und beschreibbar. Über die Erweiterung pg_graphql steht zusätzlich eine GraphQL-Schnittstelle bereit.
• Auth: Benutzerverwaltung mit E-Mail und Passwort, Magic Links, Einmalcodes, Telefonnummer und Anmeldung über externe Anbieter wie Google, Apple, GitHub oder Microsoft. Die Benutzer liegen in einem eigenen Schema der Datenbank.
• Storage: Dateiablage für Bilder, Dokumente und Videos, deren Zugriffsrechte ebenfalls über Datenbankregeln gesteuert werden.
• Realtime: ein Dienst, der Änderungen an Tabellen an verbundene Clients weiterleitet und außerdem Nachrichten zwischen Clients sowie die Anzeige anwesender Nutzer ermöglicht.
• Edge Functions: serverseitige Funktionen in TypeScript, die auf der Laufzeitumgebung Deno basieren.
• Studio: eine Weboberfläche mit Tabelleneditor, SQL-Editor, Benutzerverwaltung und Logs.

Dazu kommen Komponenten, die man selten direkt sieht: ein API-Gateway, das Anfragen an die Dienste verteilt, und ein Verbindungspool, der viele kurzlebige Verbindungen, wie sie etwa Serverless-Funktionen erzeugen, auf wenige Datenbankverbindungen bündelt.

Sicherheit mit Row Level Security

Weil Clients über die automatische API direkt auf Tabellen zugreifen, braucht Supabase einen Schutzmechanismus in der Datenbank selbst. Dafür nutzt die Plattform Row Level Security (RLS), eine Funktion von PostgreSQL: Für jede Tabelle legen Richtlinien fest, welche Zeilen ein Benutzer lesen, anlegen, ändern oder löschen darf. Die Datenbank wertet diese Richtlinien bei jeder Abfrage aus, die mit dem öffentlichen Schlüssel oder dem Token eines angemeldeten Benutzers kommt. Rollen mit dem Recht BYPASSRLS, bei Supabase etwa postgres und die Rolle hinter dem geheimen Schlüssel, umgehen RLS dagegen.

Für eine einfache Aufgabenliste, in der jeder Benutzer nur seine eigenen Einträge sieht, sieht das so aus:

create table public.tasks (
  id bigint generated always as identity primary key,
  user_id uuid not null default auth.uid()
    references auth.users (id) on delete cascade,
  title text not null,
  done boolean not null default false,
  created_at timestamptz not null default now()
);

alter table public.tasks enable row level security;

create policy "Eigene Aufgaben lesen"
  on public.tasks for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Eigene Aufgaben anlegen"
  on public.tasks for insert
  to authenticated
  with check ((select auth.uid()) = user_id);

create policy "Eigene Aufgaben ändern"
  on public.tasks for update
  to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

Die Funktion auth.uid() liefert die ID des angemeldeten Benutzers aus dem Anmeldetoken. Ist RLS aktiviert und gibt es keine passende Richtlinie, liefert die Tabelle schlicht keine Zeilen. Das ist ein sicherer Standard. Gefährlich ist das Gegenteil: eine Tabelle im öffentlichen Schema, für die RLS nie eingeschaltet wurde. Sie ist dann für jeden mit dem öffentlichen Schlüssel der App lesbar und beschreibbar. Das Studio warnt inzwischen vor solchen Tabellen, die Verantwortung bleibt aber beim Team.

Wichtig ist auch die Unterscheidung der Schlüssel. Der öffentliche Schlüssel (in neueren Projekten „publishable key“, früher „anon key“) darf in der App stehen, weil er nur so viel erlaubt, wie die RLS-Richtlinien zulassen. Der geheime Schlüssel umgeht RLS vollständig und gehört ausschließlich auf Server.

Ein Beispiel mit dem JavaScript-Client

Der offizielle Client @supabase/supabase-js liegt in Version 2 vor. Ältere Beispiele mit auth.signIn() oder .from('*').on(...) stammen aus Version 1 und funktionieren nicht mehr. Ein aktuelles Beispiel für die Aufgabenliste:

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  'https://ihr-projekt.supabase.co',
  'sb_publishable_xxxxxxxxxxxx',
);

// Anmelden mit E-Mail und Passwort
const { error: authError } = await supabase.auth.signInWithPassword({
  email: 'anna@example.com',
  password: 'ein-sicheres-passwort',
});
if (authError) throw authError;

// Neue Aufgabe anlegen – user_id setzt die Datenbank per Default
const { error: insertError } = await supabase
  .from('tasks')
  .insert({ title: 'Angebot für Kunde Müller schreiben' });
if (insertError) throw insertError;

// Offene Aufgaben lesen – RLS liefert nur die eigenen Zeilen
const { data: tasks, error } = await supabase
  .from('tasks')
  .select('id, title, done')
  .eq('done', false)
  .order('created_at', { ascending: false });
if (error) throw error;
console.log(tasks);

// Änderungen live abonnieren
supabase
  .channel('tasks-live')
  .on(
    'postgres_changes',
    { event: '*', schema: 'public', table: 'tasks' },
    (payload) => {
      console.log(payload.eventType, payload.new);
    },
  )
  .subscribe();

Damit das Abonnement Ereignisse liefert, muss die Tabelle für Realtime freigegeben sein, etwa im Studio oder per SQL mit alter publication supabase_realtime add table public.tasks;. Auch hier gelten die RLS-Richtlinien: Ein Benutzer erhält nur Änderungen an Zeilen, die er lesen darf. Ausnahme sind Löschungen: Hier lässt sich RLS nicht mehr prüfen, das Ereignis enthält dann nur den Primärschlüssel.

Für TypeScript-Projekte erzeugt das Kommandozeilenwerkzeug aus dem Datenbankschema passende Typen (supabase gen types typescript). Übergibt man sie an createClient, prüft der Compiler Tabellen- und Spaltennamen. Neben JavaScript gibt es offizielle Clients für Flutter, Swift, Kotlin und Python.

Echtzeit und Edge Functions richtig einordnen

Realtime ist bei Supabase ein Zusatzdienst, der Änderungen aus dem Transaktionsprotokoll der Datenbank liest und weiterreicht. Das funktioniert gut für Benachrichtigungen, Statusanzeigen und kollaborative Listen. Der Client bekommt aber einzelne Zeilenänderungen, keine fertig berechneten Abfrageergebnisse. Wer eine sortierte, gefilterte Liste aktuell halten will, setzt sie im Client aus den Ereignissen zusammen oder lädt sie neu. Bei sehr vielen Abonnenten auf stark beschriebenen Tabellen empfiehlt der Hersteller, statt Datenbankänderungen den Broadcast-Kanal zu nutzen. Plattformen wie Convex, die jede Abfrage automatisch reaktiv machen, sind hier näher am Ideal, verlangen dafür aber ein eigenes Datenmodell.

Edge Functions schließen die Lücke für Logik, die nicht in die Datenbank gehört: Webhooks eines Zahlungsanbieters, der Versand von E-Mails oder Aufrufe eines Sprachmodells. Eine minimale Funktion sieht so aus:

// supabase/functions/hallo/index.ts
import { withSupabase } from 'npm:@supabase/server@1';

export default {
  fetch: withSupabase({ auth: ['publishable', 'secret'] }, async (req) => {
    const { name } = (await req.json()) as { name?: string };
    return Response.json({ gruss: `Hallo ${name ?? 'Welt'}` });
  }),
};

Die Funktion exportiert einen fetch-Handler, wie es die Supabase-Dokumentation zeigt. withSupabase aus dem Paket @supabase/server lässt dabei nur Aufrufe mit dem öffentlichen oder geheimen Schlüssel des Projekts durch; so legt auch supabase functions new hallo die Vorlage an. Veröffentlicht wird die Funktion mit supabase functions deploy hallo. Viel Geschäftslogik lässt sich aber auch ohne Funktionen abbilden, nämlich direkt in PostgreSQL mit Funktionen, Triggern und Views. Was dafür spricht und wo die Grenze liegt, beschreibt der Beitrag über PostgreSQL als vollständige Backend-Lösung.

Lokal entwickeln und selbst betreiben

Für die Entwicklung startet das Kommandozeilenwerkzeug den kompletten Stack lokal in Docker-Containern:

npx supabase init     # legt den Ordner supabase/ mit Konfiguration an
npx supabase start    # startet Datenbank, Auth, Storage, Realtime und Studio lokal
npx supabase migration new tasks   # legt eine SQL-Migration an
npx supabase db push  # spielt Migrationen in das verknüpfte Cloud-Projekt ein

Schemaänderungen liegen dabei als SQL-Migrationen im Repository und lassen sich wie Code prüfen und versionieren. Das ist ein klarer Vorteil gegenüber Werkzeugen, bei denen das Datenmodell nur in einer Weboberfläche existiert.

Für den Produktivbetrieb ohne Supabase Cloud stellt der Hersteller eine Docker-Compose-Konfiguration bereit. Damit laufen alle Dienste auf eigenen Servern oder bei einem europäischen Hoster. Man sollte den Aufwand aber nicht unterschätzen: Backups, Updates der einzelnen Komponenten, Überwachung, Hochverfügbarkeit der Datenbank und das sichere Verwalten der Schlüssel liegen dann beim eigenen Team. Einige Funktionen der Cloud-Variante, etwa Branching für Vorschauumgebungen oder bestimmte Auswertungen im Dashboard, stehen im Selbstbetrieb nicht oder nur eingeschränkt zur Verfügung. Für Unternehmen ohne Datenbankbetrieb im Haus ist die gehostete Variante mit EU-Region meist die realistischere Wahl.

Kosten, Regionen und Datenschutz

Supabase Cloud bietet einen kostenlosen Tarif für kleine Projekte und kostenpflichtige Tarife mit monatlicher Grundgebühr und nutzungsabhängigen Zusatzkosten. Kostenlose Projekte werden laut Hersteller nach einer Woche ohne Aktivität pausiert. Für Produktivanwendungen ist der kostenlose Tarif daher nicht gedacht. Konkrete Preise und Kontingente ändern sich und sollten vor der Entscheidung auf der Preisseite geprüft werden.

Beim Anlegen eines Projekts wählt man die Region, darunter Frankfurt. Damit liegen die Daten in der EU. Vertragspartner ist allerdings laut Nutzungsbedingungen die Supabase Pte. Ltd. mit Sitz in Singapur, und die Infrastruktur läuft bei großen Cloud-Anbietern, vor allem AWS. Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, Unterauftragnehmer und mögliche Drittlandübermittlungen nach Art. 44 ff. DSGVO muss jedes Unternehmen selbst prüfen. Wer hier keine Kompromisse eingehen will, hat mit dem Selbstbetrieb eine echte Alternative, die es bei Firebase nicht gibt.

Supabase, Firebase, Appwrite und Convex im Vergleich

Alle vier Plattformen lösen dasselbe Grundproblem, setzen aber unterschiedliche Schwerpunkte:

• Firebase ist am längsten am Markt, bringt Push-Nachrichten, Absturzanalyse und Analytics mit und ist eng mit Google Cloud verzahnt. Es arbeitet überwiegend mit NoSQL-Dokumenten und lässt sich nicht selbst betreiben.
• Supabase setzt auf PostgreSQL und SQL. Stärken sind Abfragen über mehrere Tabellen, Auswertungen, Integration in bestehende Datenwerkzeuge und die Möglichkeit, die Datenbank mitzunehmen.
• Appwrite ist ebenfalls quelloffen und selbst betreibbar, abstrahiert die Datenbank aber hinter eigenen APIs und bietet zusätzlich Messaging und Hosting.
• Convex verzichtet auf direkten Datenbankzugriff vom Client und macht stattdessen TypeScript-Funktionen reaktiv.

Bei einem Umstieg von Firebase ist das Datenmodell die größte Hürde. Verschachtelte Dokumente werden zu Tabellen mit Fremdschlüsseln, Sicherheitsregeln zu RLS-Richtlinien. Supabase stellt dafür Migrationswerkzeuge für Benutzer und Daten bereit, die Umgestaltung des Modells nehmen sie einem aber nicht ab.

Was das für Ihr Team bedeutet

Supabase ist für viele Projekte ein guter Mittelweg zwischen „alles selbst bauen“ und einem geschlossenen Baukasten. Die Plattform spart den Aufwand für Anmeldung, APIs und Dateiablage, ohne die Daten in ein proprietäres Format zu zwingen. Wer SQL beherrscht oder lernen will, bekommt ein Backend, dessen Wissen auch außerhalb der Plattform trägt.

Unsere Einschätzung: Supabase lohnt sich besonders für Fachanwendungen, interne Werkzeuge und Produkte, bei denen Daten später ausgewertet oder mit anderen Systemen verbunden werden. Unterschätzt wird oft, dass RLS-Richtlinien echter Sicherheitscode sind, der Tests und Reviews braucht. Und wer sehr viel Logik in die Datenbank verlagert, sollte früh Regeln für Migrationen, Code-Reviews von SQL und Tests festlegen. Für Apps, die vor allem Push-Nachrichten, Analytics und mobile Werkzeuge brauchen, bleibt Firebase der bequemere Weg.

Wenn Sie ein Backend mit Supabase planen, eine bestehende Anwendung anbinden oder die Sicherheitsrichtlinien prüfen lassen möchten, finden Sie auf unserer Seite zur API-Integration und Backend-Entwicklung passende Beratungsangebote.

Häufige Fragen zu Supabase

Ist Supabase kostenlos?

Die Software selbst ist quelloffen und kostenlos nutzbar, auch im Selbstbetrieb. Der gehostete Dienst hat einen kostenlosen Tarif mit Einschränkungen. Für produktive Anwendungen fallen in der Regel monatliche Kosten an.

Braucht man SQL-Kenntnisse für Supabase?

Für die ersten Schritte nicht unbedingt, denn Tabellen lassen sich im Studio per Oberfläche anlegen. Für Sicherheitsrichtlinien, Indizes und sauberes Datenmodell sind SQL-Grundkenntnisse aber sehr hilfreich. Das ist Wissen, das auch außerhalb von Supabase nützt.

Lässt sich Supabase mit einem bestehenden Backend kombinieren?

Ja. Häufig nutzen Teams nur Auth und Datenbank und betreiben eigene Dienste daneben, die sich mit dem geheimen Schlüssel oder direkt per Postgres-Verbindung anbinden. Umgekehrt lässt sich eine bestehende Datenbank nicht ohne Weiteres in Supabase einhängen, wohl aber per Migration übernehmen.

Wie gut skaliert Supabase?

Die Datenbank skaliert so, wie PostgreSQL skaliert: vertikal über größere Instanzen und für Lesezugriffe über Replikate. Damit RLS-Richtlinien nicht bremsen, empfiehlt der Hersteller einen Index auf jeder Spalte, nach der eine Richtlinie filtert, und den Aufruf (select auth.uid()) statt auth.uid().