Supabase Alternative 2026: Welches Backend passt?

Die passende Supabase Alternative hängt davon ab, welcher Teil von Supabase ersetzt werden soll: Appwrite bietet ein vollständiges Backend mit Self-Hosting-Option, Neon ermöglicht einen Wechsel mit Postgres als Grundlage, und Firebase eignet sich für mobile Apps mit laufend synchronisierten Dokumentdaten. Die sieben Optionen ersetzen unterschiedliche Teile des Stacks. Wenn Datenbank, Anmeldung und Zugriffsregeln bereits zur Anwendung passen, spricht vieles dafür, bei Supabase zu bleiben.

Am 14. November 2026 anhand der Preislisten und Dokumentation der Anbieter geprüft. Der Vergleich stützt sich auf die Dokumentation, nicht auf eigene Praxistests oder eine Leistungsrangliste.

Welche Supabase Alternative ersetzt welchen Teil des Backends?

Bevor die Kosten verglichen werden, muss der Umfang des Wechsels feststehen. Eine verwaltete Datenbank kann den bisherigen Speicherort der Tabellen ersetzen. Eine Backend-Plattform liefert zusätzlich die Dienste, über die eine Anwendung Nutzer anmeldet, Dateien speichert und serverseitigen Code ausführt.

Eine CU-Stunde ist die Abrechnungseinheit von Neon für Datenbank-Rechenleistung. Der Preis dafür entspricht keiner vollständigen Monatsrechnung. Auch Firebase und Amplify bieten keinen einheitlichen Abopreis, der sämtliche Backend-Ressourcen abdeckt. Die in den einzelnen Abschnitten verlinkten Preislisten belegen diese Einstiegsangebote.

Was die einzelnen Optionen ersetzen

Die zusammengefassten Spalten halten den vollständigen Vergleich übersichtlich. „Dateispeicher“ meint Datei- oder Objektspeicher, nicht den Speicherplatz der Datenbank. „Self-Hosting“ bedeutet, das Backend selbst zu betreiben; ein andernorts bereitgestelltes Frontend reicht dafür nicht aus.

Überraschend ist hier Neon. Das aktuelle Produkt umfasst Authentifizierung, Objektspeicher und Funktionen; Echtzeitfunktionen befinden sich in der Beta. Die Beschreibung „nur eine Datenbank, ohne Auth oder Dateispeicher“ würde dem heutigen Angebot nicht gerecht.

Zuerst die Backend-Architektur festlegen

Postgres beibehalten, wenn der Wert der Anwendung bereits in SQL steckt. PostgreSQL, meist kurz Postgres genannt, ist die relationale Datenbank hinter Supabase. Sie speichert zusammengehörige Datensätze in Tabellen und erlaubt Abfragen über deren Verknüpfungen. Wenn Kunden, Rechnungen und Berechtigungen dort bereits funktionieren, erspart dieses Modell eine unnötige Neuentwicklung.

Wer als Gründer eine Rechnungsanwendung umzieht, sollte deshalb zunächst Optionen prüfen, die Postgres erhalten, bevor eine neue Dokumentdatenbank infrage kommt. Entscheidend ist, ob das Zielsystem die geschäftskritischen Abfragen und Zugriffsregeln unterstützt, nicht ob sein Dashboard einfacher aussieht.

Das gesamte Backend ersetzen, wenn die integrierten Dienste das Problem sind. Werden ein anderes Anmeldesystem, eine andere Datei-API, eine andere Funktionslaufzeit und ein anderes Betriebsmodell benötigt, muss das Gesamtpaket bewertet werden. Appwrite und Nhost sind dafür relevante Kandidaten. Auch Neons erweitertes Dienstangebot gehört in diese Prüfung.

Das Datenmodell nur für einen konkreten Nutzen in der Anwendung ändern. Die Dokumentsynchronisierung von Firebase, das reaktive Programmiermodell von Convex und das schlanke Backend von PocketBase im Eigenbetrieb können einen Umbau rechtfertigen. Eine unliebsame Rechnung, deren Kostentreiber unbekannt sind, kann das nicht.

Falls die einzelnen Dienste noch schwer auseinanderzuhalten sind, erklärt der Überblick zur Supabase-Architektur, welche Komponenten Daten, Identitäten, Dateien und Anwendungslogik verwalten.

Sieben Alternativen und der jeweilige Migrationsaufwand

1. Appwrite: erste Wahl für ein vollständiges Backend

Appwrite ersetzt das breite Dienstepaket von Supabase: Authentifizierung, Datenbanken, Dateispeicher, Funktionen und Echtzeitfunktionen. Es ist der erste Kandidat, wenn diese Dienste zusammengehören sollen und eine echte Wahl zwischen verwalteter Cloud und eigener Infrastruktur wichtig ist.

Für Gründer, die ein Kundenportal entwickeln, liegt der Vorteil auf der Hand: Anmeldung, Kundendatensätze, hochgeladene Dokumente und serverseitige Aktionen lassen sich auf derselben Plattform unterbringen. Das ist als Angebot deutlich besser mit Supabase vergleichbar als reines Datenbankhosting.

Bei den Datenbanken lohnt ein genauer Blick. Das aktuelle Angebot nutzt TablesDB als serverlosen Standard und führt dedizierte Optionen wie PostgreSQL, MySQL und Dokumentdatenbanken auf. Die Wahl von PostgreSQL macht jedoch weder Supabase-Clientaufrufe noch Speicherberechtigungen oder die Auth-Integration automatisch portabel. Die Kompatibilität der Datenbank-Engine und die Kompatibilität der Anwendungs-API müssen getrennt geprüft werden.

Appwrite ist Open Source und unterstützt Self-Hosting mit Docker oder Kubernetes. Der Leitfaden zum Self-Hosting benennt die betriebliche Verantwortung klar: Wartung und Skalierung liegen beim Betreiber. Diese Option ist wertvoll, wenn Kontrolle wichtig ist; niedrigere Kosten im Eigenbetrieb garantiert sie nicht.

Was gegen Appwrite spricht: Wenn die bestehende Postgres-Architektur direkt weitergenutzt werden soll, kann die Anpassung an Appwrites Dienstschnittstellen mehr Arbeit erzeugen als einsparen. Im kostenlosen Cloud-Tarif wird das Projekt bei Erreichen der Ressourcengrenzen eingefroren. Kontingente für Prototypen sollten nicht ungeprüft zur Grundlage des Produktivbetriebs werden.

Geeignet für: Gründer, die ein breites Backend-Paket mit der Möglichkeit zum Self-Hosting suchen.
Besonderheit: Umfangreiche Dienste sowohl in der verwalteten Cloud als auch im Eigenbetrieb.
Preis: Pro ab $25/Monat laut Appwrite-Preisliste.
Kostenlos testen: Es gibt einen kostenlosen Cloud-Tarif, nicht nur eine zeitlich begrenzte Testphase.

Appwrite vor dem Umzug gezielt prüfen

1. 1

   Einen typischen Nutzerablauf auswählen

   Ein Kunde meldet sich an, liest seinen eigenen Datensatz und lädt ein privates Dokument hoch. Dieser Ablauf prüft mehr vom Backend als eine öffentliche Aufgabenliste.

2. 2

   Alle Abhängigkeiten zuordnen

   Datenbankabfrage, Identitätsprüfung, Speicherberechtigung und serverseitige Aktion dieses Ablaufs erfassen. Für jede Abhängigkeit festlegen, welcher Appwrite-Dienst sie ersetzen soll.

3. 3

   Einen isolierten Nachweis aufbauen

   Mit kopierten, nicht sensiblen Datensätzen und einem Testkonto arbeiten. Prüfen, ob das Konto auf sein eigenes Dokument zugreifen kann und der Zugriff auf das Dokument eines anderen Kunden gesperrt bleibt.

4. 4

   Die Betriebsverantwortung klären

   Erst dann zwischen Cloud und Self-Hosting wählen, wenn die Zuständigkeiten für Backups, Upgrades und die Reaktion auf Störungen feststehen. Anschließend bewerten, ob die Migration das ursprüngliche Problem löst.

2. Neon: Postgres im Mittelpunkt, inzwischen mit weiteren Backend-Diensten

Neon ist hier der stärkste Ausgangspunkt, wenn Postgres erhalten bleiben soll, während die Dienste darum herum neu bewertet werden. Datenbank-Branching erzeugt getrennte Datenbankumgebungen. So lassen sich Schemaänderungen erproben, ohne die Produktion zur Experimentierfläche zu machen.

Ein Beispiel ist eine SaaS-Anwendung, deren Geschäftslogik bereits auf dem eigenen Server liegt. Sie benötigt möglicherweise einen anderen Datenbankhoster, ohne zugleich den Anmeldeanbieter oder Dateidienst ersetzen zu müssen. Ein enger begrenzter Umzug hält das Vorhaben überschaubar.

Neon kann inzwischen auch mehr übernehmen. Das Produktupdate zum Backend dokumentiert Managed Better Auth, Funktionen und S3-kompatiblen Objektspeicher. Diese Dienste können gemeinsam mit der Datenbank verzweigt werden. Echtzeitfunktionen sind derzeit in der Beta. Wenn das Produkt von Live-Zusammenarbeit abhängt, muss dieser Status bewertet werden, bevor er zum Wechselgrund wird.

Der Datenbankkern ist im Open-Source-Repository des Anbieters verfügbar. Das ist etwas anderes als ein fertig nutzbares, selbst gehostetes Gegenstück zum gesamten Cloud-Backend. Neon sollte wegen seines verwalteten Dienstes gewählt werden; ein verfügbares Repository bedeutet nicht, dass für jedes Feature ein müheloser Ausstieg möglich ist.

Was gegen Neon spricht: Die Anwendung hängt von eng verzahntem Dienstverhalten ab, das weiterhin angepasst werden muss, oder sie benötigt einen ausgereiften Ersatz für einen Echtzeitpfad, der hier noch in der Beta ist. SQL beizubehalten verringert den Datenbankumbau, beseitigt aber nicht die Migration der Dienste.

Geeignet für: Bestehende Postgres-Anwendungen und Entwickler, die isolierte Datenbankumgebungen benötigen.
Besonderheit: Branching umfasst inzwischen neben Tabellen auch zugehörige Backend-Dienste.
Preis: Launch wird nach Nutzung abgerechnet, mit $0.106 pro CU-Stunde für Rechenleistung und weiteren Ressourcenkosten; siehe Neon-Preisliste.
Kostenlos testen: Ein Free-Tarif ist verfügbar.

3. Firebase: für mobile Abläufe mit Dokumentdaten

Firebase passt zu Anwendungen, deren Kernfunktionen von Live-Daten und Offline-Nutzung abhängen, besonders auf Mobilgeräten. Die Datenbank Cloud Firestore speichert Dokumente in Sammlungen und unterstützt Echtzeit-Listener sowie Offline-Betrieb, wie die Firestore-Dokumentation beschreibt.

Ein Beispiel ist eine Außendienst-App, in der Mitarbeiter Auftragsdaten bei wechselnder Netzverfügbarkeit aktualisieren. Das ist ein konkreter Anlass, Firestores Clientverhalten zu prüfen. Eine bestehende Rechnungsdatenbank nur deshalb dorthin zu verlagern, weil beide Plattformen eine Anmeldung anbieten, ist deutlich weniger überzeugend.

Firebase kann die wesentlichen Backend-Aufgaben über Authentication, Firestore, Cloud Storage und Cloud Functions übernehmen. Es ist ein proprietäres, verwaltetes Backend, kein produktiver Stack, der sich auf den eigenen Server mitnehmen lässt. Der übliche Weg über Firestore verändert außerdem die Organisation und Abfrage der Daten.

Eine wichtige Einschränkung: Firebase führt inzwischen SQL Connect auf, das auf Cloud SQL for PostgreSQL basiert. „Firebase hat keine SQL-Option“ ist daher zu pauschal. Dieser Weg muss als eigene Architektur bewertet werden; die Dokumentsemantik von Firestore und SQL Connect sind nicht einfach austauschbar.

Was gegen Firebase spricht: Die Anforderungen an relationale Abfragen wachsen über das gewählte Dokumentmodell hinaus, oder unabhängiges Hosting und ein leichter nachvollziehbarer Zusammenhang zwischen Nutzung und Kosten werden wichtig. Ein Wechsel von Supabase zu Firestore bedeutet, Abfragen und Zugriffsregeln zu übertragen, statt einen Postgres-Dump wiederherzustellen.

Geeignet für: Mobile und Webanwendungen, die von Firestores Live- und Offline-Verhalten für Dokumente profitieren.
Besonderheit: Dokumentsynchronisierung auf Clientseite.
Preis: Blaze wird nach Verbrauch abgerechnet; die Firebase-Preisliste nennt keinen einheitlichen festen Monatspreis.
Kostenlos testen: Spark ist kostenlos, die aktuelle Tarifübersicht verlangt für Cloud Storage und Cloud Functions jedoch Blaze.

Eine ausführlichere Gegenüberstellung der Architekturen bietet Supabase im Vergleich mit Firebase.

4. Nhost: Postgres behalten und GraphQL bewusst wählen

Nhost passt am ehesten, wenn ein Postgres-Backend mit einer auf GraphQL ausgerichteten API gesucht wird. GraphQL ist eine Abfragesprache, über die der Client bestimmte Felder und verknüpfte Datensätze anfordern kann. Der Stack kombiniert Postgres, die GraphQL-API von Hasura, Authentifizierung, Dateispeicher und serverlose Funktionen.

Für ein Kundenportal, das ein Konto zusammen mit dessen Projekten und den jeweils jüngsten Aktivitäten anzeigt, kann diese API-Struktur gut zum Frontend passen. Der Wechselgrund ist dann die gewünschte Anwendungsschnittstelle, nicht die Annahme, dass sich alle Postgres-Plattformen gleich verhalten.

Das Quellcode-Repository von Nhost beschreibt einen Open-Source-Stack und ein Self-Hosting-Beispiel mit Docker Compose. Es dokumentiert außerdem die lokale Entwicklung mit nachverfolgten Datenbankmigrationen und Hasura-Metadaten. Diese Metadaten sind wichtig: API-Konfiguration und Berechtigungen gehören ebenso zur Anwendung wie das Datenbankschema.

Was gegen Nhost spricht: Die Konfigurationsschicht aus GraphQL und Hasura soll nicht zusätzlich gepflegt werden. Wenn der eigene Server die benötigten Endpunkte bereits bereitstellt, kann eine weitere API-Schicht neue Verantwortung schaffen, ohne ein Kundenproblem zu lösen.

Durch Postgres erhalten die Daten ein vertrautes Zielsystem. Supabase-Zeilenrichtlinien werden dadurch aber nicht automatisch in die rollenbasierte API-Autorisierung von Nhost übersetzt. Das sind getrennte Abnahmekriterien.

Geeignet für: Teams, die ausdrücklich Postgres mit einem auf GraphQL ausgerichteten Backend wollen.
Besonderheit: Integrierte GraphQL-Abonnements, Identitätsverwaltung und Dateispeicher rund um Postgres.
Preis: Pro ab $25/Monat; organisationsweite Tarife stehen auf der Nhost-Preisseite.
Kostenlos testen: Starter ist kostenlos; inaktive Projekte werden pausiert.

5. Convex: das reaktive Programmiermodell als Wechselgrund

Convex ersetzt Datenbankzugriff und serverseitige Anwendungslogik durch ein reaktives Backend, das über JavaScript- oder TypeScript-Funktionen angesprochen wird. Auth, Dateispeicher und zeitgesteuerte Aufgaben gehören ebenfalls zum Angebot.

Eine gemeinsame Planungs-App ist ein passender Kandidat: Mehrere Personen bearbeiten dieselben Aufgaben, und die Oberfläche muss den veränderten Zustand abbilden. Convex ist dann sinnvoll, wenn die Entwicklung um dieses Verhalten herum aufgebaut werden soll. Eine bestehende SQL-Anwendung lässt sich dagegen nicht unverändert übernehmen.

Die Datenbankdokumentation trifft eine hilfreiche Unterscheidung: Convex speichert JSON-ähnliche Dokumente und unterstützt relationale Modellierung. Es ist kein Postgres; ihm grundsätzlich Beziehungen zwischen Daten abzusprechen, wäre aber ebenfalls falsch. Lesen und Schreiben erfolgen über die Funktions-API statt über SQL.

Self-Hosting wird unterstützt. Die Dokumentation zur Backend-Lizenz beschreibt eine Fair-Source-Lizenz mit Einschränkungen für konkurrierende Hosting-Dienste und einer späteren Apache-Lizenz. Das verdient eine präzisere Einordnung als ein uneingeschränktes Häkchen bei „Open Source“.

Was gegen Convex spricht: SQL-Kompatibilität und das Postgres-Werkzeugumfeld werden wichtiger als das reaktive Anwendungsmodell. Self-Hosting kann den Betriebsort von Convex ändern; aus seinen Abfragen wird dadurch kein SQL.

Geeignet für: Entwickler, die für eine neue oder bewusst neu aufgebaute Anwendung ein reaktives Backend wählen.
Besonderheit: Datenfunktionen und reaktives Anwendungsverhalten in einem gemeinsamen Programmiermodell.
Preis: Starter beginnt laut Convex-Preisliste bei $0/Monat zuzüglich Nutzung.
Kostenlos testen: Ein Free-Tarif ist verfügbar.

6. PocketBase: klein und selbst gehostet, mit klarer Einschränkung für die Produktion

PocketBase bündelt Datenbank, Authentifizierung, Echtzeit-Abonnements, Dateispeicher und Verwaltungsoberfläche in einem kleinen Backend für den Eigenbetrieb. Durch die eingebettete SQLite-Datenbank unterscheidet es sich sowohl von verwaltetem Postgres als auch von einer Zusammenstellung aus Cloud-Diensten.

Für ein internes Geräteverzeichnis oder ein überschaubares Community-Tool kann eine einzelne ausführbare Backend-Datei ein attraktives Betriebsmodell sein. Trotzdem muss jemand Bereitstellung, Backups, Überwachung und Upgrades übernehmen. „Eine Datei“ beschreibt die Paketierung, nicht das Ende der Betriebsaufgaben.

Die Einführung des Anbieters erklärt, dass PocketBase weiterhin aktiv entwickelt wird, noch keine vollständige Abwärtskompatibilität garantiert und für produktionskritische Anwendungen nicht empfohlen wird, sofern manuelle Migrationsarbeiten nicht akzeptiert werden. Dieser Hinweis ist wichtiger als ein spekulativer Vergleich der Skalierbarkeit.

PocketBase ist Open Source und wird selbst gehostet. Es ersetzt mehrere nutzerseitige Backend-Funktionen, ist aber weder ein verwalteter Hosting-Tarif noch ein direktes Ziel für die Wiederherstellung einer Supabase-Postgres-Datenbank. Das SQLite-Datenmodell und die Anwendungs-API erfordern eigene Migrationsarbeiten.

Was gegen PocketBase spricht: Die Anwendung wird so kritisch, dass stärkere Betriebsgarantien nötig sind, als der Betreiber selbst leisten möchte, oder die Verantwortung für Upgrades passt nicht mehr zum Projekt.

Geeignet für: Kleine Anwendungen, deren Verantwortliche die Wartung im Eigenbetrieb bewusst übernehmen.
Besonderheit: Datenbank, Auth, Dateien und Echtzeitfunktionen in einer kompakten eigenständigen Anwendung.
Preis: Der Anbieter führt kostenlose Software und keinen kostenpflichtigen Hosting-Tarif auf; die Infrastruktur kommt separat hinzu.
Kostenlos testen: Für die Nutzung der Software ist kein Hosting-Testzugang nötig.

7. AWS Amplify: sinnvoll bei bestehendem AWS-Betrieb

AWS Amplify passt zu Teams, die ihr Anwendungsbackend auf AWS-Diensten aufbauen und die zugehörigen Dienstgrenzen verwalten wollen. Der standardmäßige Datenpfad nutzt Amazon DynamoDB mit einer AWS-AppSync-API und Echtzeit-Abonnements.

Für ein Unternehmen, das bereits in einem AWS-Konto arbeitet, kann das gut passen: Amazon Cognito übernimmt die Identitätsverwaltung, Amazon S3 die Dateien und AWS Lambda bei Bedarf individuelle Backend-Logik. Für alleinige Gründer, die ihr erstes Backend auswählen, bedeuten dieselben Dienstgrenzen zusätzliche Konzepte, die im Fehlerfall verstanden werden müssen.

Der Leitfaden zur Dateneinrichtung von Amplify zeigt, wie TypeScript-Modelldefinitionen Datenbank- und API-Ressourcen erzeugen. Dieses Grundgerüst kann die Entwicklung beschleunigen. Bei einer Supabase-Migration müssen SQL-Daten, Berechtigungen und Funktionen dennoch auf die gewählten AWS-Dienste abgebildet werden.

Die JavaScript-Bibliotheken sind Open Source. Die verwalteten AWS-Dienste dahinter sind kein portables Backend zum Self-Hosting. Bereitstellungen im eigenen AWS-Konto bedeuten Kontrolle über diese Cloud-Konfiguration, keine Unabhängigkeit von AWS.

Was gegen Amplify spricht: Die Anwendung ist so einfach, dass die Koordination der AWS-Dienste mehr Betriebsaufwand verursacht als ein enger integriertes Backend-Paket.

Geeignet für: Teams, die bereits für den Anwendungsbetrieb auf AWS aufgestellt sind.
Besonderheit: Ein im Code definierter Zugang zu Identitätsverwaltung, Daten, Dateispeicher und Funktionen von AWS.
Preis: Für die Backend-Nutzung gibt es keinen monatlichen Mindestbetrag; die zugrunde liegenden Dienste werden laut Amplify-Preisliste nach Nutzung abgerechnet.
Kostenlos testen: Die Verfügbarkeit des AWS Free Tier hängt vom Dienst und der Berechtigung des Kontos ab.

Für eine neue Bewertung sollte die aktuelle Amplify-Dokumentation der Ausgangspunkt sein. Anleitungen müssen dieselbe Einrichtung beschreiben, die tatsächlich verwendet werden soll.

Welche Alternative zu Supabase passt zum Vorhaben?

Appwrite wählen, wenn das vollständige Backend-Paket benötigt wird. Für genau diese Aufgabe steht es hier an erster Stelle, weil es einen breiten Dienstumfang mit einem ausdrücklich vorgesehenen Weg zum Self-Hosting verbindet. Wenn der Erhalt von Postgres und die Einführung von GraphQL wichtiger sind, fällt die Empfehlung stattdessen auf Nhost.

Neon wählen, wenn Postgres die erste feste Vorgabe ist. Zuerst die Datenbankmigration planen und danach entscheiden, welche zusätzlichen Dienste sinnvoll sind. Ein überschaubarer Datenbankumzug sollte nicht allein deshalb zum Umbau der Identitätsverwaltung werden, weil beide Dienste beim selben Anbieter verfügbar sind.

Firebase oder Convex wählen, wenn das Anwendungsverhalten den Umbau rechtfertigt. Firestore von Firebase passt zu Live-Dokumenten und Offline-Clients, Convex zu einem reaktiven Modell mit Datenfunktionen. In beiden Fällen ist ein funktionierender Nachweis des schwierigsten Nutzerablaufs wertvoller als der Umzug der einfachsten Tabelle.

PocketBase für bewusst gewählte Einfachheit, Amplify bei bestehender AWS-Bindung wählen. Keines von beiden ist eine universelle Ausweichlösung. PocketBase verlagert Verantwortung zum Betreiber, Amplify verteilt sie auf AWS-Dienste.

Gehen die Anforderungen an die Vektorsuche über pgvector hinaus, sollte Pinecone als separate Retrieval-Schicht geprüft werden, nicht als Ersatz für das Supabase-Backend.

Wann es richtig ist, bei Supabase zu bleiben

Bleiben ist sinnvoll, wenn SQL-Modell, Anmeldung und Row-Level Security bereits zum Produkt passen und der vorgeschlagene Ersatz sie ohne wesentlichen Nutzen nur nachbauen würde. Row-Level Security, kurz RLS, ist das Regelsystem der Datenbank, mit dem jeder Kunde ausschließlich seine eigenen Datensätze sehen kann.

Ein funktionierendes Kundenportal wird nicht besser, nur weil seine Datensätze in ein anderes Dashboard umziehen. Eine lohnende Migration sollte ein benennbares Problem lösen: benötigtes Clientverhalten, eine Betriebsanforderung, eine Dienstbeschränkung oder ein belegtes Kostenproblem.

Supabase Kosten: zuerst die Ursache bestimmen

Zunächst klären, ob der Tarif, die Rechenleistung, Dateien, Datenverkehr oder eine andere Ressource die Kosten verursacht. Die Aufschlüsselung der Supabase-Preise behandelt die Kaufentscheidung ausführlich. Verglichen werden müssen alle Dienste, die die Anwendung nach dem Umzug weiterhin benötigt, einschließlich jener, die eine reine Datenbankmigration zurücklassen würde.

Was kostet der Dateispeicher bei Supabase?

Wenn hochgeladene Dateien das Problem sind, kann ein Wechsel der Datenbank-Engine an der eigentlichen Ursache vorbeigehen. Vor der Wahl eines vollständig neuen Backends sollten die gespeicherten Inhalte und ihre Downloads geprüft werden. Eine reine Umstellung des Dateispeichers ist ein eigenes Projekt, zu dessen Umfang auch Dateizugriffsregeln und Anwendungs-URLs gehören.

Was lässt sich aus Supabase mitnehmen, was muss neu aufgebaut werden?

Die Postgres-Daten sind der portable Teil; eine funktionierende Anwendung besteht aus weit mehr als Tabellenzeilen. Supabase dokumentiert die logische Sicherung und Wiederherstellung von Rollen, Schema und Daten. Speicherobjekte und Edge Functions behandelt der Leitfaden zu Backup und Wiederherstellung als separate Migrationsarbeiten.

Für ein anderes Postgres-Ziel ist die Datenbank damit ein sinnvoller Ausgangspunkt. Bevor eine Wiederherstellung als ausreichend gilt, müssen unterstützte Erweiterungen, Versionen und anwendungsspezifische Abhängigkeiten geprüft werden. Bei Firestore, Convex oder SQLite ist stattdessen mit Datenumwandlung und neu geschriebenen Abfragen zu rechnen.

Auth braucht einen Plan für die Identitäten. Laut Supabases Leitfaden zur Wiederherstellung im Eigenbetrieb können Nutzerdatensätze in einem Datenbank-Dump enthalten sein, während JWT-Secrets, Anbietereinstellungen und Weiterleitungs-URLs separat konfiguriert werden müssen. Beim dort dokumentierten Umzug auf eine neue selbst gehostete Instanz werden bestehende Tokens ungültig; Nutzer müssen sich erneut anmelden.

Dieser Leitfaden behandelt eine Wiederherstellung von Supabase zu Supabase. Er verspricht nicht, dass ein anderer Anbieter jedes Konto importieren oder jede Sitzung erhalten kann. Bei einem Anbieterwechsel muss vor der Terminierung der Umschaltung feststehen, wie Konten, Identitätskennungen und Anmeldemethoden zugeordnet werden.

RLS lässt sich exportieren, seine Bedeutung hängt aber vom umgebenden Identitätssystem ab. Die Richtlinien sind Postgres-Objekte und kein grundsätzlich unportabler Code. Supabases RLS-Dokumentation enthält allerdings Hilfsfunktionen wie auth.uid() und auth.jwt(). Das Zielsystem muss den passenden Identitätskontext liefern, andernfalls müssen die Richtlinien angepasst werden. Ein erfolgreicher SQL-Import beweist noch nicht, dass Kundendaten weiterhin voneinander abgeschottet sind.

Edge Functions brauchen Prüfungen von Laufzeit und Integration. Supabase beschreibt sie im Leitfaden zu Edge Functions als portable TypeScript-Funktionen auf einer Deno-kompatiblen Laufzeit. Die Migrationsarbeit steckt in Bereitstellung, Secrets, Gateway-Authentifizierung und Rückrufen an Supabase-Dienste. Bei einer inkompatiblen Ziellaufzeit können außerdem Codeänderungen nötig werden.

Vor dem Produktionsumzug muss der vollständige Ablauf isoliert nachgewiesen werden: anmelden, erlaubte Datensätze lesen, unerlaubte Zugriffe abweisen, eine private Datei hochladen und abrufen sowie die entscheidende Geschäftsaktion ausführen. Ein Rückweg bleibt nötig, bis diese Abläufe im Zielsystem funktionieren.

Wie die Auswahl zustande kam

Der Vergleich umfasst die sieben im Briefing genannten Kandidaten und deren primäre Produktseiten, geprüft am 14. November 2026. Die Auswahlkriterien sind Ersatzumfang, Fortführung der Datenbank, Unterstützung für Identitäten und Dateien, Echtzeitverhalten, Kontrolle über das Hosting, Einstieg in kostenpflichtige Angebote und Verantwortung bei der Migration.

Es wurden weder Tests mit angemeldeten Konten noch Durchsatzmessungen oder Latenz-Benchmarks durchgeführt. Die Empfehlungen sind Architekturentscheidungen auf Basis der dokumentierten Fähigkeiten. Entscheidend ist, ob eine Option die Anforderungen mit weniger Gesamtaufwand an der Anwendung erfüllt, nicht die Anzahl der Feature-Bezeichnungen auf ihrer Startseite.

Allgemeine Hosting-Anbieter zählen hier nicht als zusätzliche Backend-Alternativen: Ein gemieteter Server ersetzt für sich genommen weder Auth noch Dateiberechtigungen oder Anwendungs-APIs. Ein Datenbankdienst wird berücksichtigt, wenn er ein sinnvolles Migrationsziel bietet; die verbleibenden Arbeiten an den Diensten werden dabei ausdrücklich benannt.

Von welchen Optionen ist abzuraten?

PocketBase meiden, wenn eine produktionskritische Migration nicht selbst gewartet werden kann. Die Warnung des Anbieters ist ein Auswahlkriterium, keine Fußnote, die sich wegdiskutieren lässt.

Amplify meiden, wenn niemand die AWS-Dienstkonfiguration verantwortet. Das generierte Grundgerüst ersetzt nicht das Verständnis der zugrunde liegenden Ressourcen.

Firestore von Firebase oder Convex nicht allein wählen, um bestehendes SQL anderswo unterzubringen. Beide bieten Gründe für ihr jeweiliges Programmiermodell; keines erspart den SQL-Umbau.

Neons erweitertes Backend nicht mit garantierter Supabase-Kompatibilität gleichsetzen. Jeder zu ersetzende Dienst muss geprüft werden, besonders wenn die Echtzeitfunktionen in der Beta unverzichtbar für die Anwendung sind.

Und eine funktionierende Supabase-Anwendung sollte nicht allein für ein Freikontingent umziehen. Zuerst muss nachgewiesen werden, dass der Ersatz ein Problem löst, dessen Gewicht Migration und laufenden Betrieb überwiegt.

Häufige Fragen

Ist Supabase gut oder schlecht?

Supabase passt gut, wenn Postgres mit integrierter Authentifizierung, Dateien und serverseitigen Funktionen gefragt ist. Es passt schlecht, wenn Anwendung oder Betrieb ein anderes Modell verlangen. Bestehendes SQL und vorhandene Zugriffsrichtlinien sprechen dafür, vor einem Wechsel zunächst das Bleiben zu prüfen.

Welche guten Alternativen gibt es zu MongoDB?

Das ist eine andere Fragestellung als der Ersatz für Supabase. Für dokumentorientierte Anwendungsdaten kommen Firestore oder Convex infrage; für den Wechsel zu relationalem SQL eine Postgres-Option. Keine dieser Entscheidungen bedeutet automatische Kompatibilität mit einer bestehenden MongoDB-Anwendung.

Lässt sich Supabase kostenlos nutzen?

Ja. Die aktuelle Supabase-Tarifseite enthält einen Free-Tarif mit Ressourcenkontingenten. Ob er zur Anwendung passt, hängt von den benötigten Diensten und der Nutzung ab. Kostenloser Zugang bedeutet keine unbegrenzte Produktionskapazität.

Sind Supabase und Firebase das Gleiche?

Nein. Beide decken typische Backend-Anforderungen ab, aber Supabase stellt Postgres ins Zentrum. Firestore von Firebase nutzt Dokumente und Client-Synchronisierung; SQL Connect ist ein separater Weg auf PostgreSQL-Basis. Verglichen werden sollte die konkrete Architektur, die tatsächlich eingesetzt werden soll.

Gibt es eine bessere Option als Supabase?

Für bestimmte Anforderungen gibt es passendere Optionen: Appwrite für ein breites Paket mit Self-Hosting, Neon für einen Postgres-orientierten Wechsel, Nhost für GraphQL, Firebase für mobile Abläufe mit Firestore und Convex für reaktive Datenfunktionen. Ohne konkrete Anforderung ist Bleiben oft die bessere Entscheidung.

Warum wird Firebase Studio eingestellt?

Google dokumentiert die Einstellung von Firebase Studio zum 22. März 2027 und verweist bestehende Workspace-Nutzer auf Google AI Studio oder Google Antigravity. Die Studio-Mitteilung belegt kein darüber hinausgehendes geschäftliches Motiv und erklärt ausdrücklich, dass die zentralen Firebase-Produkte und bereits bereitgestellte Apps nicht betroffen sind.

Was ersetzt Google Firebase?

Die obige Mitteilung nennt keinen einzelnen Ersatz für das Firebase-Backend. Die dort genannten Migrationsziele betreffen die Entwicklungsumgebung Firebase Studio. Ein alternatives Backend ist nur dann sinnvoll, wenn dessen Datenbank-, Hosting- oder Anwendungsmodell besser zu den Anforderungen passt.

Welche Nachteile hat Firebase?

Beim Weg über Firestore benötigt eine bestehende SQL-Anwendung ein anderes Daten- und Abfragemodell. Die produktiven Dienste bleiben an Googles verwaltete Infrastruktur gebunden, und die nutzungsabhängige Abrechnung verlangt einen Blick auf die einzelnen Ressourcen. Spark enthält zudem nicht jeden Dienst, der für ein vollständiges Backend nötig ist.

Was passiert mit Firebase?

Firebase Studio wird eingestellt; laut Google sind die zentralen Backend-Produkte von Firebase davon nicht betroffen. Der Lebenszyklus der Workspace-Anwendung darf nicht mit der Verfügbarkeit von Firestore, Authentication oder anderen Backend-Diensten verwechselt werden.

Die Checkliste zur Prüfung von KI-Geschäftsabläufen hilft, den vom Backend zu unterstützenden Ablauf zu erfassen, bevor die Entscheidung für eine Migration fällt.