Supabase erklärt: Das Backend für KI-gebaute Apps

Supabase liefert Ihrer App 1 vollwertige Postgres-Datenbank sowie Dienste für Anmeldung, Dateien, serverseitigen Code, Echtzeitaktualisierungen und Vektorsuche. Die Plattform kann das Backend bereitstellen, mit dem ein KI-App-Builder die Oberfläche verbindet. Wer auf Daten zugreifen darf, wer das Projekt kontrolliert und wie ein Umzug aussehen würde, muss trotzdem geklärt werden.

Was ist Supabase, und welche Rolle spielt es in einer App?

Supabase ist eine Backend-Plattform auf Basis von gehostetem PostgreSQL, meist kurz Postgres genannt. Diese Datenbank speichert Datensätze in miteinander verknüpften Tabellen. Das Backend ist der Teil einer App, der Daten behält und Regeln durchsetzt, auch nachdem jemand den Browser geschlossen hat. Das Frontend ist die Oberfläche, die Nutzer sehen und bedienen.

Jedes Supabase-Projekt erhält eine vollwertige Postgres-Datenbank. Die ergänzenden Dienste bringen Funktionen mit, die sonst einzeln entwickelt oder angebunden werden müssten. Datensätze lassen sich im Table Editor des Dashboards einsehen, Datenbankabfragen im SQL Editor schreiben oder aus dem Anwendungscode heraus ausführen. Das sind verschiedene Zugänge zu derselben Datenbank, wie die Datenbankübersicht erläutert.

Ein Kundenportal lässt sich mit einem Gebäude samt Gebäudeservice vergleichen. Das Frontend ist der öffentliche Eingang. Postgres verwahrt die Datensätze, Auth prüft Identitäten, Storage speichert Dateien, und serverseitige Funktionen erledigen Aufgaben, die Besucher nicht selbst ausführen sollten. Supabase stellt einen großen Teil dieser Infrastruktur bereit. Welche Kunden welche Räume betreten dürfen, muss die App weiterhin selbst regeln.

Das ist hier mit Backend as a Service, kurz BaaS, gemeint: Verwaltete Backend-Komponenten ersetzen den Eigenbau und Eigenbetrieb jedes einzelnen Bausteins. Die Geschäftsregeln der Anwendung sind damit noch nicht geschrieben.

Am 7. November 2026 anhand der aktuellen Produktdokumentation geprüft. Die folgenden Entscheidungen betreffen Datenstruktur, Zugriffskontrolle, Entwicklungsabläufe und Portabilität. Eine bestimmte Kapazität für Datenverkehr oder eine Verfügbarkeitsgarantie wird dabei nicht vorausgesetzt.

Wofür wird Supabase eingesetzt?

Supabase passt zu Apps, die dauerhaft gespeicherte Datensätze, Benutzerkonten und darauf abgestimmte Berechtigungen benötigen. Typische Beispiele sind Kundenportale, Buchungsdienste, interne Verwaltungstools oder Mitgliederangebote. Eine statische Landingpage ohne Konten und gespeicherte Anwendungsdaten braucht ein solches Backend möglicherweise gar nicht.

Ein Beispiel ist ein Agenturportal, in dem Kunden Briefings hochladen, Arbeitsergebnisse freigeben und den Projektstatus sehen. Die Datenbank könnte Kunden mit ihren Projekten und jedes Projekt mit seinen Freigaben verknüpfen. Ein hochgeladenes PDF gehört in den Dateispeicher; ein Datenbankeintrag kann festhalten, wer es hochgeladen hat und zu welchem Projekt es gehört. Das sind unterschiedliche Aufgaben, auch wenn das Dashboard beides gemeinsam darstellt.

Eine KI-generierte Oberfläche zeigt zunächst vielleicht nur Beispielprojekte im Browser. Durch die Anbindung an Supabase erhält der erzeugte Code einen Ort, an dem er Daten dauerhaft lesen und schreiben kann. Damit ist noch nicht belegt, dass die erzeugten Beziehungen, Berechtigungen oder Freigaberegeln zum Unternehmen passen.

Supabase erzeugt außerdem eine Web-API aus dem Datenbankschema, also der Struktur der Tabellen und ihrer Beziehungen. Eine API ist eine Schnittstelle, über die Software Aufgaben bei einem anderen System anfordert. Laut Data-API-Dokumentation lässt sie sich direkt im Browser oder zusammen mit einem eigenen Anwendungsserver nutzen. Deshalb kann ein App-Builder eine erzeugte Oberfläche anbinden, ohne zunächst für jede grundlegende Datenbankoperation einen eigenen Serverendpunkt schreiben zu müssen.

In der Praxis verteilen sich die Aufgaben so:

Für Gründer zählt bei der Übergabe ein konkret benanntes Backend-Projekt, das sich einsehen lässt und dessen Regeln jemand erklären kann. Eine funktionierende Vorschau allein beantwortet diese Fragen nicht.

Die Bausteine im Überblick

Jede Komponente übernimmt einen anderen Teil der Anwendung. Zum Einstieg reichen die tatsächlich benötigten Bausteine. Ein einfaches Portal mit Benutzerkonten braucht weder Live-Zusammenarbeit noch semantische Suche, nur weil diese Funktionen verfügbar sind.

Postgres: die gespeicherten Datensätze der App

Postgres speichert strukturierte Daten in Tabellen und verknüpft zusammengehörige Datensätze. Im Agenturportal sind Kunden, Projekte und Freigaben unterschiedliche Arten von Datensätzen mit Beziehungen untereinander. SQL ist die Sprache, mit der diese Daten abgefragt und geändert werden. Eine Frage wie „Welche Projekte warten noch auf die Freigabe dieses Kunden?“ kann diesen Beziehungen folgen. Supabase baut auf dieser Datenbank auf, statt sie durch ein proprietäres Tabellenformat zu ersetzen. Die Architekturdokumentation beschreibt die zugrunde liegenden Open-Source-Komponenten und standardisierten Exportverfahren. Die Grenze liegt im Datenmodell: Unklare Zuständigkeiten oder Beziehungen bleiben unklar, auch wenn ein KI-Tool die Tabellen anlegt.

Was macht Supabase Auth?

Supabase Auth verwaltet Benutzerkonten und Anmeldeverfahren, darunter Passwörter, per E-Mail versandte Magic Links, Einmalpasswörter und Social Login. Der Dienst stellt ein signiertes Identitätstoken aus, das die App bei späteren Anfragen mitsenden kann. Im Portal stellt Auth fest, welcher Kunde sich anmeldet; die Zugriffsrichtlinien der Datenbank bestimmen, welche Projekte dieser Kunde lesen darf. Die Auth-Dokumentation trennt ausdrücklich zwischen Authentifizierung, also der Identitätsprüfung, und Autorisierung, also der Berechtigungsprüfung. Eine generierte Anmeldemaske kann daher korrekt funktionieren, während die Datenberechtigungen der App weiterhin falsch sind. „Anmeldung möglich“ und „Zugriff nur auf die richtigen Datensätze“ sind getrennte Abnahmekriterien.

Storage: die Dateien hinter den Datensätzen

Supabase Storage speichert Bilder, Dokumente, Videos und andere Dateien; Postgres speichert ihre Metadaten, also die Informationen, die sie beschreiben. In einem Portal ist das Briefing-PDF ein gespeichertes Objekt. Die Projektzuordnung und der Eigentümer können als Datenbankeinträge vorliegen. Die Storage-Übersicht dokumentiert Dateiauslieferung und Zugriffsrichtlinien sowie spezielle Analytics- und Vektor-Buckets. Entscheidend ist die Unterscheidung zwischen einer Datei und einer Tabellenzeile, die diese Datei beschreibt. Der Schutz der Projekttabelle belegt für sich genommen noch nicht, dass auch der Downloadpfad einer Datei privat ist. Es muss feststehen, welche Uploads öffentlich sind und welche ausschließlich einem angemeldeten Kunden gehören.

Edge Functions: Aufgaben auf dem Server

Supabase Edge Functions führen serverseitiges TypeScript in einer Deno-kompatiblen Laufzeitumgebung aus. TypeScript ist eine Programmiersprache; die Laufzeitumgebung führt ihren Code aus. Die Funktionen können Webhooks empfangen, also Benachrichtigungen anderer Dienste, und externe APIs aufrufen. Beispielsweise könnte eine Zahlungsbenachrichtigung eine Funktion auslösen, die das Ereignis prüft und den Kontostatus aktualisiert. Der Leitfaden zu Edge Functions beschreibt auch den Einsatz für E-Mails und Aufrufe von KI-Diensten. Hier gehören vertrauenswürdige Serveraufgaben hin, wenn der Browser weder Zugangsdaten enthalten noch selbst über das Ergebnis entscheiden sollte. Auch Funktionen benötigen Autorisierung und Fehlerbehandlung. Ein generierter Endpunkt klärt beides noch nicht.

Was leistet Supabase Realtime?

Supabase Realtime übermittelt Aktualisierungen an verbundene Clients: über Broadcast-Nachrichten, Presence-Informationen zu verbundenen Nutzern und Abonnements für Änderungen in Postgres. Im Portal könnte sich dadurch der Projektstatus auf dem Bildschirm einer anderen Person ohne manuelles Neuladen ändern. Eine Oberfläche für die Zusammenarbeit könnte außerdem anzeigen, wer gerade anwesend ist. Die Realtime-Dokumentation führt diese Fähigkeiten getrennt auf. Sie unterstützen die Interaktion in Echtzeit, bestimmen aber weder den Umgang mit widersprüchlichen Änderungen noch einen Offline-Ablauf für die App. Realtime lohnt sich, wenn Nutzer Änderungen sofort sehen müssen. Für ein gewöhnliches Formular können ein gespeicherter Datensatz und eine aktualisierte Ansicht ausreichen.

Vektorsuche: nach ähnlicher Bedeutung suchen

Supabase unterstützt Vektorsuche in Postgres über pgvector, eine Erweiterung zum Speichern und Vergleichen von Embeddings. Ein Embedding ist eine numerische Darstellung von Inhalten, mit der sich Ähnlichkeit ermitteln lässt. Ein Portal könnte so Briefings zu ähnlichen Kundenproblemen finden, auch wenn sie anders formuliert sind. Die Dokumentation zu KI und Vektoren behandelt das Speichern, Indexieren und Abfragen von Embeddings sowie semantische Suche, Stichwortsuche und hybride Suche. Damit steht ein Baustein zur Informationssuche für ein KI-Feature bereit. Er liest jedoch nicht automatisch jedes hochgeladene PDF, erzeugt dessen Embeddings, wählt die passenden Zugriffsfilter oder liefert eine verlässliche Antwort. Diese Schritte müssen Teil der entwickelten Anwendung sein.

Wie KI-App-Builder und Coding-Agenten Supabase nutzen

KI-App-Builder verbinden generierten Anwendungscode mit einem Backend. Coding-Agenten können zusätzlich Werkzeuge erhalten, mit denen sie das Backend selbst untersuchen oder verändern. Beides kann Entwicklungsarbeit sparen. Dabei entstehen unterschiedliche Zugriffswege, und dieser Unterschied wird relevant, sobald echte Kundendaten hinzukommen.

Lovable: eigenes Projekt oder integriertes Backend

Die Supabase-Integration von Lovable kann eine App mit einem eigenen Supabase-Projekt verbinden, Datenbankstrukturen anlegen, Migrationen ausführen, Funktionen bereitstellen und die Oberfläche an Daten anbinden. Eine Migration ist eine dokumentierte Datenbankänderung, etwa das Anlegen einer Tabelle oder das Ändern einer Spalte. Laut aktueller Integrationsdokumentation ist außerdem Lovables integriertes Backend standardmäßig aktiviert und nutzt die Open-Source-Grundlage von Supabase. Deshalb benötigt nicht jede Lovable-App ein separates Supabase-Konto.

Daraus ergibt sich die Frage, wer die Anbindung kontrolliert. „Nutzt Supabase-Technologie“ bedeutet noch nicht, dass ein Projekt in der eigenen Supabase-Organisation mit direktem Dashboard-Zugriff existiert. Laut Lovable erfolgt der Wechsel zwischen integriertem Backend und eigenem Supabase-Projekt nicht automatisch. Welche Variante gewünscht ist, sollte feststehen, bevor sich Kundendaten und Konfiguration ansammeln.

Bolt: App-Versionsverlauf und Datenbankverlauf unterscheiden

Bolt kann Supabase für Datenbankzugriff, Authentifizierung und Edge Functions anbinden. Laut aktuellem Leitfaden zur Supabase-Integration erhalten neue Projekte standardmäßig eine Bolt-Datenbank. Um eine Datenbank in Supabase anzubinden oder zu übernehmen, ist ein Pro- oder Teams-Tarif erforderlich. Soll das geplante System direkt in Supabase verwaltet werden, muss diese Verbindung gezielt eingerichtet werden.

Eine wesentliche Einschränkung betrifft die Wiederherstellung: Bolts Version History stellt eine Supabase-Datenbank nicht wieder her. Wird die Anwendung auf eine ältere Version zurückgesetzt, bleibt die aktuelle Datenbank bestehen. Hat eine generierte Änderung gespeicherte Daten gelöscht oder umgewandelt, sind die Wiederherstellung der alten Oberfläche und die Wiederherstellung dieser Daten verschiedene Vorgänge. Bevor die Rückgängig-Funktion des Builders als Wiederherstellungsplan gilt, muss ein solcher Plan für die Datenbank vorliegen.

v0: Anbindung und Werkzeugzugriff getrennt prüfen

v0 unterstützt Supabase über seine Datenbankintegrationen. Die Dokumentation zur Datenbankanbindung beschreibt, wie eine vorhandene Datenbank ausgewählt oder über den Marketplace eine neue angelegt und die Verbindung für spätere Generierungsschritte verfügbar gemacht wird. So arbeitet der Builder mit einem konkreten Backend, statt lediglich einen visuellen Entwurf zu erzeugen.

v0 dokumentiert außerdem MCP-Werkzeuge aus Marketplace-Integrationen, darunter Supabase, sowie Verbindungen zu weiteren MCP-Servern. Der MCP-Leitfaden unterscheidet zwischen Werkzeugen, die während der Generierung verfügbar sind, und Fähigkeiten, die die erzeugte App aufrufen kann. Die Anbindung eines Entwicklungswerkzeugs gibt Kunden nicht automatisch Zugriff auf dasselbe Werkzeug. Zu prüfen sind sowohl die Backend-Verbindung der Anwendung als auch die Berechtigungen des Agenten, der sie entwickelt.

Der Supabase-MCP-Server: Entwicklungszugriff mit Folgen

Das Model Context Protocol, kurz MCP, ist ein standardisierter Weg, auf dem ein KI-Agent externe Werkzeuge nutzt. Der MCP-Server von Supabase kann Werkzeuge bereitstellen, um die Datenbank zu untersuchen, SQL auszuführen, Migrationen anzuwenden, Protokolle abzufragen und Edge Functions bereitzustellen. Ein Agent muss dann nicht raten, welche Tabellen existieren, sondern kann das tatsächliche Projekt prüfen und dort Änderungen vornehmen.

Die MCP-Dokumentation von Supabase empfiehlt Entwicklungsprojekte statt Produktionsdaten, auf einzelne Projekte beschränkten Zugriff, manuelle Freigaben von Werkzeugaufrufen und gegebenenfalls einen Nur-Lese-Modus. Diese Maßnahmen beantworten unterschiedliche Fragen: Welches Projekt erreicht der Agent, welche Vorgänge darf er ausführen und welche Aktionen müssen geprüft werden? Auch lesender Zugriff kann Daten offenlegen. Er ersetzt daher nicht die Entscheidung darüber, welche Informationen der Agent sehen soll.

Die gewöhnliche App-Verbindung dient den Nutzern. Die MCP-Verbindung dient dem Entwicklungsagenten. Dessen Zugriff darf nicht so behandelt werden, als würde er automatisch die eingeschränkten Anwendungsrechte jedes Kunden übernehmen.

Das Verzeichnis für KI-Werkzeuge von Supabase unterscheidet außerdem zwischen direktem MCP-Zugriff, Agent Skills mit wiederverwendbaren Arbeitsanweisungen und Plugins, die beides bündeln. Ein kopierter Prompt ist eine weitere Anweisungsquelle, aber keine aktive Datenbankverbindung. Das umfassendere Integrationsverzeichnis verweist auf Dashboard-Integrationen, einen Partnerkatalog, Vercel Marketplace und Stripe Projects. Das sind unterschiedliche Wege, Dienste anzubinden oder bereitzustellen, keine austauschbaren Bezeichnungen für MCP.

Was ist RLS in Supabase?

Row Level Security, kurz RLS, ist das Richtliniensystem der Datenbank, das festlegt, auf welche Zeilen eine bestimmte Anfrage zugreifen darf. In einem Kundenportal könnte die Regel lauten: Ein Kunde darf Datensätze seiner Organisation lesen und ändern, erhält aber keinen Zugriff auf die Datensätze anderer Kunden.

Das Verhältnis zur Anmeldung ist klar definiert. Auth liefert die Identität. Datenbankberechtigungen, sogenannte Grants, bestimmen, ob die Rolle dieser Identität einen Vorgang auf einer Tabelle ausführen darf. RLS-Richtlinien legen fest, welche Zeilen dieser Vorgang betreffen darf. Der Leitfaden zu Row Level Security fordert dazu auf, Grants und Richtlinien gemeinsam zu konfigurieren und sowohl erlaubte als auch verweigerte Vorgänge zu testen.

Für Gründer, die eine generierte App abnehmen, ist die Trennung zwischen Kunden ein sinnvoller Prüfpunkt. Dazu werden getrennte Testkunden angelegt. Jeder muss die vorgesehenen Aktionen mit den eigenen Datensätzen ausführen können. Versuche, Datensätze des anderen Kunden zu lesen oder zu ändern, müssen dagegen scheitern. Auch ein nicht angemeldeter Besucher gehört in den Test. Ein Entwickler sollte die zugrunde liegenden Datenanfragen prüfen, denn eine ausgeblendete Schaltfläche ist keine Zugriffsrichtlinie.

Ist Supabase sicher?

Supabase stellt Mechanismen zur Zugriffskontrolle bereit. Wie sicher eine bestimmte App ist, hängt von deren Konfiguration und Nutzung ab. Eine ausgereifte Oberfläche oder eine erfolgreiche Anmeldung reicht als Beleg nicht aus. Entscheidend ist, ob eine unberechtigte Anfrage dort abgewiesen wird, wo die Daten bereitgestellt werden.

Dateien brauchen eine eigene Prüfung. Laut Dokumentation zum Bucket-Zugriff erlaubt ein öffentlicher Bucket jedem mit der URL einer Datei, diese abzurufen. Für öffentliche Bilder kann das passen. Für ein vertrauliches Kundenbriefing ist es die falsche Voreinstellung. Das Zugriffsmodell des Dateispeichers muss zusammen mit den Datenbankrichtlinien geprüft werden.

Was ist der anon-Schlüssel von Supabase?

Der Schlüssel anon ist das ältere Gegenstück zu einem veröffentlichbaren API-Schlüssel und für öffentliche Anwendungskomponenten vorgesehen. Ein API-Schlüssel identifiziert die Anwendungskomponente; die Identität des angemeldeten Nutzers wird separat übermittelt. Die aktuelle Dokumentation zu API-Schlüsseln empfiehlt für neue Entwicklungen veröffentlichbare und geheime Schlüssel. Verwendet generierter Code ältere Begriffe, sollte ein Entwickler ihn mit der aktuellen Dokumentation abgleichen, statt bei allen Schlüsseln dieselben Rechte anzunehmen.

Geheime Schlüssel und ältere service_role-Schlüssel umgehen RLS. Sie gehören in vertrauenswürdige Backend-Komponenten mit eigenen Autorisierungsprüfungen und dürfen nicht im Browsercode ausgeliefert werden. Wird eine scheiternde Anfrage durch den Austausch gegen einen höher privilegierten Schlüssel zum Erfolg gebracht, kann genau die Kundentrennung entfallen, die die App benötigt.

Was unter eigener Kontrolle steht und was sich mitnehmen lässt

Supabase bietet eine Open-Source-Grundlage und standardisierte Postgres-Daten. Das schafft praktische Möglichkeiten für einen späteren Wechsel. Der Umzug einer vollständigen Anwendung umfasst trotzdem mehr als den Export ihrer Datenbank.

Zunächst muss die Kontrolle geklärt sein: über das Repository der App, die Supabase-Organisation und das Projekt, die Konfiguration sowie das Konto, das Zugriffe verwalten kann. Wurde das Backend von einem Dienstleister oder Builder eingerichtet, muss dieser zeigen, wo diese Kontrollmöglichkeiten liegen. Hier geht es um die Zuständigkeit für den Betrieb, nicht um die Behauptung, alle Builder hätten dieselben Kontomodelle.

Anschließend gibt es zwei unterschiedliche Wege für einen Umzug. Entweder wechselt die App zu einer anderen Supabase-Installation und behält die umgebenden Dienste, oder die Datenbank zieht zu einem anderen Postgres-Host um und die aufgerufenen Supabase-spezifischen Dienste werden ersetzt. Die SQL-Daten beizubehalten hilft in beiden Fällen. Die zweite Variante ist deshalb aber noch lange nicht mit einem geänderten Verbindungsstring erledigt.

Der Leitfaden zur Wiederherstellung aus der Plattform auf einer selbst gehosteten Installation zeigt die Abgrenzung:

Datenbankfunktionen und Edge Functions sind unterschiedliche Dinge. Erstere laufen innerhalb von Postgres und gehören zur Datenbankdefinition. Letztere sind Anwendungscode, der in der Funktionslaufzeit ausgeführt wird. Wer beides verwechselt, hält einen Export leicht für vollständiger, als er ist.

Für den Eigenbetrieb empfiehlt Supabase Docker, eine Software, die die Dienste der Plattform in Containern ausführt. Die Self-Hosting-Dokumentation überträgt die Verantwortung für Serverwartung, Sicherheitsupdates, Datenbankwartung, Backups, Wiederherstellung und Überwachung auf den Betreiber. Sie nennt außerdem verwaltete Funktionen, die dort nicht verfügbar sind: darunter verwaltetes Branching, verwaltete Backups und die zeitpunktgenaue Wiederherstellung, mit der eine Datenbank auf einen gewählten früheren Zeitpunkt zurückgesetzt wird, sowie Vektor-Buckets. Open Source verspricht somit keinen identischen Funktionsumfang mit der Cloud.

Für ein kleines Unternehmen ohne eigene Betriebsverantwortliche ist verwaltetes Supabase der sinnvollere Einstieg. Der Ausstiegsplan sollte verständlich bleiben, doch allein die Möglichkeit zum Eigenbetrieb ist kein Grund, ihn zu übernehmen. Wenn Kontrolle über die Infrastruktur erforderlich ist, sollten die Wiederherstellung und die Einrichtung der umgebenden Dienste vor dem verbindlichen Umzug erprobt werden.

Wann passt Supabase, wann ein anderes Backend?

Maßgeblich sind die Daten und Betriebsanforderungen der Anwendung. Die Empfehlung eines KI-App-Builders erleichtert die Integration, ersetzt aber keine vollständige Architekturentscheidung.

Ist Supabase eine gute Wahl?

Supabase passt gut, wenn eine App verknüpfte Geschäftsdaten verwaltet und vom Zusammenspiel aus Datenbankzugriff, Authentifizierung, Dateien und Serverlogik profitiert. Ein Agenturportal mit kundeneigenen Projekten ist ein klarerer Anwendungsfall als eine reine Informationswebsite. Die Wahl ist sinnvoll, wenn jemand die Datenbeziehungen und Berechtigungsregeln erklären und pflegen kann, auch wenn die KI einen großen Teil der Umsetzung schreibt.

Die Grenze liegt in der Verantwortung für die Anwendung. Supabase hostet Komponenten. Die Plattform entscheidet nicht, ob ein Kunde weitere Nutzer einladen darf, ob eine Freigabe widerrufen werden kann oder ob ein Mitarbeiter alle Konten sehen darf. Ist für diese Entscheidungen niemand zuständig, löst auch ein anderes Backend das Problem nicht.

Tarife, enthaltene Nutzung und Mehrverbrauch behandelt unser Leitfaden zu den Supabase-Kosten.

Firebase: wenn Offline-Abläufe mit Dokumenten im Mittelpunkt stehen

Firebase verdient einen genaueren Blick, wenn ein offlinefähiger mobiler Arbeitsablauf die zentrale Anforderung ist und die Daten in ein Dokumentenmodell passen. Cloud Firestore, die Dokumentendatenbank von Firebase, unterstützt zwischengespeicherte Lese- und Schreibvorgänge und synchronisiert sie, sobald das Gerät wieder verbunden ist. Die Firestore-Dokumentation beschreibt dieses Verhalten. Ein Außendienstmitarbeiter, der Besuche ohne verlässliche Verbindung dokumentiert, ist ein konkreter Anlass, es zu prüfen.

Die Abwägung verlangt, dieses Datenmodell und sein Synchronisationsverhalten bewusst zu wählen und zu verstehen. Firestore ist kein ohne Weiteres austauschbarer Ersatz für eine App, die auf relationalen Tabellen basiert. Ebenso ist „Firebase ist ausschließlich NoSQL“ inzwischen zu pauschal: Google dokumentiert unter Firebase SQL Connect auch ein verwaltetes PostgreSQL-Angebot. Verglichen werden sollten die konkreten Datenbankprodukte, nicht nur die Plattformnamen. Unser Vergleich von Supabase und Firebase vertieft diese Entscheidung.

Neon: wenn Branching den Entwicklungsablauf prägt

Neon ist prüfenswert, wenn isolierte Datenbankzweige ein zentraler Bestandteil der Entwicklung und der Tests sind. Ein Branch gibt einer geplanten Änderung einen eigenen Datenbankzustand, in dem sie erprobt werden kann, bevor sie den übergeordneten Zweig beeinflusst. Die Branching-Dokumentation beschreibt unabhängige Entwicklungs- und Testumgebungen, einschließlich reiner Schema-Branches, wenn Produktionsdaten nicht kopiert werden sollen.

Die Entscheidung zwischen Supabase und Neon sollte nicht auf der überholten Unterscheidung „vollständiges Backend gegen reine Datenbank“ beruhen. Neons aktuelle Produktdokumentation führt auch Authentifizierung, Storage, Funktionen und Echtzeitfähigkeiten auf. Die Dokumentation zur verwalteten Authentifizierung beschreibt Nutzer- und Sitzungsdaten, die gemeinsam mit der Datenbank verzweigt werden. Entscheidend sind der benötigte Entwicklungsablauf und das Verhalten der Dienste. Bestehende Supabase-Dienstaufrufe umzustellen erfordert weiterhin Integrationsarbeit.

Ein reiner Postgres-Host: wenn der Rest schon vorhanden ist

Ein reiner Postgres-Host kann die passendere Lösung sein, wenn der bestehende Anwendungsserver Anmeldung, Autorisierung, Dateispeicherung und Hintergrundaufgaben bereits übernimmt. Dann werden möglicherweise nur eine verwaltete Datenbankverbindung und der Datenbankbetrieb des Hosts benötigt, statt weiterer Anwendungsdienste.

Dafür bleiben Zusammenbau und Wartung in eigener Verantwortung. Das gilt für das umgebende Backend ebenso wie für die dafür ausgewählten Dienste. Bei einem bestehenden Produkt, das diese Bausteine schon besitzt, kann das angemessen sein. Wer als Gründer mit generierten Oberflächen und ohne Backend beginnt, muss dagegen womöglich erheblich mehr Entscheidungen treffen, bevor die App durchgängig funktioniert.

Was wird bei Supabase übertrieben dargestellt?

Überzogen ist die Vorstellung, ein angebundenes Backend mache eine generierte App bereits verlässlich nutzbar. Eine funktionierende Verbindung zeigt, dass Komponenten miteinander kommunizieren können. Korrekte Berechtigungen, Wiederherstellbarkeit und die richtige Umsetzung der Geschäftsregeln beweist sie nicht.

„Open Source bedeutet einen Umzug ohne Aufwand“ ist eine weitere Übertreibung. Die Exportmöglichkeiten sind wertvoll, aber die oben beschriebenen Arbeiten an Dateien und Konfiguration bleiben bestehen. „Vektorsuche macht aus der App ein KI-Produkt“ überspringt Dokumentaufbereitung, Suchqualität, Berechtigungen und das Modell, das eine Antwort erzeugt. „Realtime bedeutet Offline-Synchronisation“ verwechselt unmittelbare Aktualisierungen mit der eigenständigen Anforderung, auch ohne Verbindung arbeiten zu können.

Auch für die Rechenleistung gibt es eine konkrete Grenze. Die Limits für gehostete Edge Functions von Supabase betragen 256 MB Arbeitsspeicher und 2 Sekunden CPU-Zeit pro Anfrage. Wartezeit auf asynchrone Ein- oder Ausgabe wird dabei nicht mitgezählt. Eine Funktion, die auf einen externen Dienst wartet, unterscheidet sich von einer Funktion, die diese Zeit für Berechnungen verbraucht. Rechenintensive Verarbeitung benötigt eine passende Worker-Architektur. Ein höherer Tarif hebt nicht automatisch jede Laufzeitbeschränkung auf.

Diese Grenzen helfen dabei, Aufgaben richtig zu verteilen. Ein Portal, das eine Benachrichtigung empfängt und einen Datensatz aktualisiert, erzeugt eine andere Last als eines, das große Mediendateien verarbeitet. Die sinnvolle Frage lautet, welche Arbeit wo ausgeführt wird, statt der Plattform eine unbegrenzte Fähigkeit zur „Skalierung“ zuzuschreiben.

Was vor dem Einsatz mit echten Kundendaten geklärt sein muss

Passt Supabase zur App, kann die Entwicklung weitergehen. Vor der Aufnahme echter Kundendaten muss die Backend-Übergabe jedoch ausdrücklich geklärt werden. Wer eine bestehende App übernimmt, sollte zunächst die aktuelle Konstellation prüfen, bevor Anbieter gewechselt werden. Wer als Gründer lediglich eine öffentliche Informationswebsite erstellt, kann warten, bis dauerhaft gespeicherte Anwendungsdaten tatsächlich gebraucht werden.

1. 1

   Das selbst kontrollierte Backend identifizieren

   Builder oder Entwickler müssen das konkrete Projekt, die kontrollierende Organisation, das Repository der Anwendung und die Konfiguration der Backend-Verbindung zeigen. Dabei ist zu klären, ob es sich um ein eigenes Supabase-Projekt oder das verwaltete Backend des Builders handelt.

2. 2

   Die Trennung zwischen Kunden nachweisen

   Es muss belegt sein, dass ein Testkunde auf eigene Datensätze zugreifen kann und fremde Datensätze weder lesen noch ändern darf. Dazu gehören Anfragen ohne Anmeldung, Downloads privater Dateien und serverseitige Aktionen. Neben der Oberfläche sind die zugrunde liegenden Anfragen zu prüfen.

3. 3

   Entwicklungsänderungen von Kundendaten trennen

   Der Coding-Agent erhält ein Entwicklungsprojekt und nur die benötigten Werkzeuge. Migrationen und Berechtigungsänderungen werden vor der Übernahme in den Produktivbetrieb geprüft. Der Zugriff des Entwicklungsagenten bleibt vom Zugriff der App-Nutzer getrennt.

4. 4

   Wiederherstellung und Ausstieg konkret festlegen

   Zu klären ist, wer gelöschte Daten wiederherstellt, woher Dateien zurückgespielt werden und welcher Funktionscode sowie welche Einstellungen erneut bereitgestellt werden müssen. Die Antwort wird bei der App dokumentiert. Ein Codeexport oder der Versionsverlauf eines Builders darf nicht die gesamte Antwort sein.

Der nächste Schritt für die kommende Woche ist eine kurze Vorführung am tatsächlichen Projekt: Wer kontrolliert es, wie werden Kunden voneinander getrennt und wie funktioniert die Wiederherstellung? Kann der Builder diese Punkte nicht erklären, sollten sie vor dem nächsten Feature fertiggestellt werden.

Häufige Fragen von Gründern zu Supabase

Wie funktioniert die Authentifizierung mit Supabase?

Supabase Auth verwaltet die Anmeldung und stellt Identitätstoken aus. Die App sendet das Token des Nutzers mit ihren Anfragen; Datenbank- und Storage-Richtlinien bestimmen, worauf dieser Nutzer zugreifen darf. Die Anmeldung einzubauen und Kundenberechtigungen festzulegen sind getrennte Aufgaben.

Was ist mit superbase gemeint?

Falls das Backend-Produkt gemeint ist: Es heißt Supabase. Es verbindet eine Postgres-Datenbank mit Diensten wie Authentifizierung, Storage, Funktionen und Echtzeitaktualisierungen. „Superbase“ ist nicht die Schreibweise dieses Produkts.

Welche Vorteile bietet Supabase?

Der wichtigste Vorteil sind integrierte Backend-Dienste rund um eine standardisierte Postgres-Datenbank. Anwendungen mit Benutzerkonten lassen sich entwickeln, ohne jede Komponente einzeln zusammenzustellen. Gleichzeitig bleiben Datenbankexport und Eigenbetrieb möglich. Berechtigungen müssen trotzdem entworfen und die Anwendung verantwortlich betrieben werden.

Was ist besser als Supabase?

Firebase mit Firestore kann besser zu einem Offline-Arbeitsablauf mit Dokumenten passen. Neon ist prüfenswert, wenn Branching die Entwicklung prägt. Ein reiner Postgres-Host kann sich für eine Anwendung eignen, deren umgebende Backend-Dienste bereits vorhanden sind. Supabase ist eine gute Wahl, wenn seine integrierten Komponenten zur geplanten App passen.

Nutzen auch große Unternehmen Supabase?

Supabase veröffentlicht Kundengeschichten, darunter eine zu eXp Realty. Das belegt die Nutzung, ist aber kein Versprechen zu Kapazität oder Verfügbarkeit des eigenen Projekts. Maßgeblich sind die konkrete Architektur und die Betriebsanforderungen der eigenen App.

Eignet sich Supabase für Anfänger?

Verwaltete Komponenten und ein visueller Datenbankeditor können den Einstieg erleichtern. Auch Anfänger müssen Datensätze, Beziehungen und Zugriffsregeln verstehen oder mit jemandem zusammenarbeiten, der das tut. KI kann bei der Umsetzung helfen; das fertige Verhalten muss überprüft werden.

Warum ist Supabase so beliebt?

Der praktische Reiz liegt darin, dass häufig benötigte Anwendungsfunktionen um dasselbe Postgres-Projekt angeordnet sind, mit APIs und Integrationen für App-Builder. Dadurch müssen weniger einzelne Backend-Komponenten verbunden werden. Das bedeutet nicht, dass jede App jeden Supabase-Dienst benötigt.

Weitere praxisnahe Erklärungen zu den Werkzeugen hinter KI-gebauten Produkten gibt es im Newsletter.