Supabase vs. Firebase vs. Neon vs. Upsun Cloud: Postgres-Integration im Produktionsmaßstab im Jahr 2026

Vier Plattformen tauchen immer wieder auf, wenn ein Team entscheidet, wie eine App mit einer Datenbank ausgestattet werden soll: Supabase und Firebase als umfassende Backend-as-a-Service-Plattformen, die eine Datenbank mit Authentifizierung, Speicher und Echtzeitfunktionen bündeln; Neon als Spezialist für serverloses Postgres, der mittlerweile eine eigene Authentifizierungsebene integriert; und Upsun Cloud als Multi-Cloud-Anwendungsplattform mit verwaltetem Postgres als einem von mehreren erstklassigen Diensten. Es handelt sich nicht um die gleiche Art von Produkt, und ein Prototyp wird die entscheidenden Unterschiede nicht aufzeigen. Der Produktionsverkehr hingegen schon.

Eine Klarstellung, die es vorweg zu treffen gilt: Die Datenbank von Firebase, Firestore, ist kein Postgres. Es handelt sich um eine NoSQL-Dokumentendatenbank mit einem völlig anderen Abfragemodell. Sie wird hier berücksichtigt, weil Teams sie bei der Auswahl eines Backends tatsächlich mit Supabase und Neon vergleichen – nicht, weil sie einen Integrationsweg für Postgres bietet. Wo diese Unterscheidung die Empfehlungen beeinflusst, wird in diesem Leitfaden direkt darauf hingewiesen.

Die wichtigsten Erkenntnisse

• Dieser Leitfaden vergleicht vier Plattformen, die Teams für ein App-Backend in Betracht ziehen, wobei der Fokus darauf liegt, was sich ändert, sobald der Datenverkehr ab 2026 Produktionsmaßstäbe erreicht.
• Supabase und Firebase sind beides Backend-as-a-Service-Plattformen, die Datenbank, Authentifizierung, Speicher und Echtzeitfunktionen bündeln; Neon und Upsun Cloud sind keine vollständigen BaaS-Plattformen und setzen voraus, dass ein Team seine eigene Anwendungsschicht mitbringt oder hostet.
• Firebases Firestore ist eine NoSQL-Dokumentendatenbank, kein Postgres. Seine echte Stärke in der Produktivumgebung – synchrone Schreibvorgänge über mehrere Regionen hinweg mit starker Konsistenz – beruht auf dieser unterschiedlichen Architektur, nicht trotz ihr.
• Upsun Cloud eignet sich am besten für Teams, die eine echte, portierbare PostgreSQL- oder MariaDB-Instanz wollen, die zusammen mit ihrem eigenen Anwendungscode und ihren Workers verwaltet wird – mit Compliance, die den gesamten Stack abdeckt und nicht nur die Datenbank allein.

Was jede Plattform tatsächlich ist

• Supabase stellt für jedes Projekt eine vollständige, standardmäßige Postgres-Datenbank bereit und baut darauf Auth, Storage, Realtime und Edge Functions auf. Die Datenbank ist echtes Postgres, keine Abstraktion, sodass vorhandene SQL-Befehle, Erweiterungen und Tools in der Regel funktionieren.
• 
  Firebase ist Googles Backend-Plattform für Mobilgeräte und das Web, die hauptsächlich auf Firestore, einer NoSQL-Dokumentendatenbank, sowie auf Firebase Authentication, Cloud Storage und Cloud Functions basiert. Standardmäßig gibt es keine relationale SQL-Schicht (das neuere Data Connect von Firestore fügt eine SQL-Option auf Basis einer separaten Cloud SQL Postgres-Instanz hinzu, einem anderen Produkt als Firestore selbst).
• Neon ist ein Spezialist für serverloses Postgres. Es hostet keinen Anwendungscode, führt keine Hintergrundprozesse aus und bietet keinen integrierten Speicher; es ist eine Datenbank, auf die eine neuere Authentifizierungsschicht (Neon Auth) aufgesetzt ist, anstatt als separater Dienst zu fungieren. 
   
• Upsun Cloud ist eine Multi-Cloud-Anwendungsplattform. Managed PostgreSQL und MariaDB sind zwei von mehreren erstklassigen Diensten neben Redis, Elasticsearch, OpenSearch, RabbitMQ und Kafka, doch die Kernaufgabe der Plattform besteht darin, die Anwendung selbst zu hosten – über AWS, GCP, Azure, OVHcloud oder IBM Cloud hinweg –, wobei die Datenbank nur eine von mehreren Abhängigkeiten darstellt.

Worauf du bei einer Postgres-Integration in der Produktivumgebung achten solltest

1. Echtes Postgres versus ein anderes Datenmodell. Ob die Plattform Standard-Postgres, eine Postgres-Wire-kompatible Engine oder eine grundlegend andere Datenbank wie das Dokumentenmodell von Firestore bietet.
2. Skalierung beim Lesen versus Skalierung beim Schreiben. Ob die Plattform nur Lese-Replikate hinzufügt oder Schreibvorgänge wirklich verteilt, auch über Regionen hinweg.
3. Verbindungsverwaltung bei hoher Parallelität. Ob ein Connection-Pooler standardmäßig integriert und empfohlen wird oder ob das Team diesen selbst hinzufügen muss, bevor „zu viele Verbindungen“ zu einem Produktionsvorfall werden.
4. Backups und Point-in-Time-Wiederherstellung. Was das tatsächliche Wiederherstellungsziel ist und welche Tarifstufe dafür erforderlich ist.
5. Umfang der Compliance und Kosten für deren Erreichung. Ob Zertifizierungen nur die Datenbank, die gesamte Plattform oder (im Fall von Firebase) nur eine bestimmte, namentlich genannte Teilmenge von Diensten abdecken.
6. Wo die Anwendungsschicht läuft. Ob die Plattform deinen App-Code und deine Worker hostet oder erwartet, dass du diese ganz woanders ausführst.

Supabase, Firebase, Neon und Upsun Cloud im Produktionsmaßstab

1. Supabase

Eine Backend-as-a-Service-Plattform, die auf echtem, standardmäßigem Postgres basiert, mit einer Skalierung in der Produktivumgebung, die Lesevorgänge gut abdeckt, Schreibvorgänge hingegen weniger.

Jedes Supabase-Projekt ist eine vollständige Postgres-Datenbank, die zusammen mit Auth, Storage, Realtime und Edge Functions verwaltet wird. Supabase betreibt einen Connection-Pooler namens Supavisor, und kostenpflichtige Tarife bieten zusätzlich zur Datenbank selbst einen dedizierten Pooler. Lese-Replikate sind ab dem Pro-Tarif verfügbar, darunter auch regionenübergreifende Lese-Replikate für latenzempfindliche, leseintensive Workloads, und der API-Load-Balancer von Supabase kann den Lesedatenverkehr an das nächstgelegene Replikat weiterleiten. Die Point-in-Time-Wiederherstellung ist ein kostenpflichtiges Add-on ab dem Pro-Tarif, bei dem das Write-Ahead-Log etwa alle zwei Minuten archiviert wird.

Wichtigste Funktionen:

• Vollwertiges, standardmäßiges Postgres pro Projekt, ergänzt durch Row Level Security, Auth, Storage, Realtime und Edge Functions
• Supavisor-Verbindungspooling mit einem dedizierten Pooler bei kostenpflichtigen Tarifen
• Lese-Replikate, auch regionenübergreifend, verfügbar ab dem Pro-Tarif
• Point-in-Time-Wiederherstellung als kostenpflichtiges Add-on mit einem Recovery Point Objective von etwa zwei Minuten
• SOC 2 Typ II und ISO/IEC 27001:2022 im Großen und Ganzen; HIPAA erfordert den Team-Tarif (599 $/Monat) oder den Enterprise-Tarif sowie ein separates kostenpflichtiges HIPAA-Add-on; im Pro-Tarif ist dies zu keinem Preis verfügbar

Am besten geeignet für: Teams, die eine vollständige Backend-as-a-Service-Plattform wollen, inklusive Authentifizierung, Speicher, Echtzeit- und Edge-Funktionen, aufgebaut auf einer Datenbank, die ihnen tatsächlich gehört und die sie mit Standard-SQL abfragen können.

Vorteile:

• Da Postgres als Basis dient, lassen sich vorhandene SQL-Kenntnisse, Erweiterungen (einschließlich pgvector) und Tools direkt übernehmen
• Lese-Replikate und Connection-Pooling sind wirklich produktionsreif und nicht nur angeflanscht
• Es ist eine umfassende Compliance-Abdeckung verfügbar, wenn auch nicht immer in der günstigsten Preisstufe

Nachteile:

• Lese-Replikate skalieren nur Lesevorgänge; es gibt keine Option für regionenübergreifende Schreibvorgänge, und die Rechenleistung ist auf eine einzelne Instanz (64 Kerne, 256 GB) begrenzt, anstatt weiter skaliert zu werden
• Sowohl HIPAA als auch die vollständige SOC-2-Berichterstattung erfordern das Team-Paket (599 $/Monat) oder das Enterprise-Paket; die Pro-Stufe bietet zu keinem Preis einen HIPAA-Zugangsweg

2. Firebase

Googles Backend-Plattform für Mobilgeräte und das Web, basierend auf Firestore – einer NoSQL-Dokumentendatenbank mit wirklich automatischer, regionenübergreifender und stark konsistenter Skalierung sowie einer Compliance-Abdeckung, die enger gefasst ist, als der Markenname vermuten lässt.

Firestore verteilt Daten automatisch auf Speicherserver und repliziert jeden Schreibvorgang synchron auf die Mehrheit der Replikate mithilfe eines Paxos-basierten Konsensprotokolls, ohne dass das Team eine Kapazitätsplanung vornehmen muss. In einer multiregionalen Konfiguration beherbergen zwei Regionen vollständige Replikate und eine dritte ein Witness-Replikat, sodass die Daten auch beim Ausfall einer gesamten Region les- und schreibbar bleiben – ein echter Vorteil gegenüber der asynchronen, schreibgeschützten Replikation, die jede Postgres-Option in diesem Leitfaden bietet. Firestore unterstützt außerdem die Wiederherstellung zu einem bestimmten Zeitpunkt mit einem Rollback von bis zu sieben Tagen. Der Kompromiss liegt im Datenmodell selbst: keine SQL-Joins, kein relationales Schema und Abfragemuster, die oft eine Denormalisierung der Daten oder die Erstellung von zusammengesetzten Indizes im Vorfeld erfordern.

Beim Thema Compliance wird „Firebase“ als Marke etwas irreführend. Googles HIPAA-Business-Associate-Vereinbarung (BAA) deckt eine spezifische, namentlich aufgeführte Liste von „Covered Products“ ab, darunter Firestore (unter dem Namen Google Cloud), Cloud Storage, Identity Platform und Cloud Run-Funktionen. Dienste der Marke „Firebase“, die nicht auf dieser Liste stehen – darunter Firebase Authentication, Firebase Realtime Database, Firebase Hosting und Crashlytics – fallen ausdrücklich nicht unter das BAA. Ein Projekt kann also vollständig auf „Firebase“ aufbauen und dennoch Komponenten (wie Firebase Auth) enthalten, die rechtlich gesehen keinen Zugriff auf geschützte Gesundheitsdaten haben dürfen.

Wichtigste Funktionen:

• Vollautomatische, serverlose Skalierung für Firestore, ohne manuelle Kapazitätsplanung
• Synchrone replikation über mehrere Regionen hinweg mit starker Konsistenz sowohl beim Lesen als auch beim Schreiben
• Wiederherstellung zu einem bestimmten Zeitpunkt mit Rollback bis zu sieben Tagen
• Umfassende allgemeine Compliance im Rahmen des Google Cloud-Programms (SOC 2, SOC 3, ISO 27001 und andere), wenn auch nicht speziell unter der Marke Firebase.

Am besten geeignet für: Teams, die eine automatische Skalierung über mehrere Regionen hinweg mit starker Konsistenz wünschen und ein Datenmodell entwickeln, das eher auf Dokumente als auf relationale Tabellen ausgerichtet ist, oder die sich mit den Abfragemustern von Firestore wohlfühlen.

Vorteile:

• Regionsübergreifende Schreibvorgänge mit starker Konsistenz, nicht nur Lesereplikate, von Haus aus
• Die Skalierung erfolgt wirklich automatisch; es gibt keine Recheninstanz, deren Größe angepasst werden muss
• Das sieben Tage lange Zeitfenster für die Point-in-Time-Wiederherstellung ist länger als das, was die meisten Postgres-Optionen in diesem Leitfaden standardmäßig bieten

 Nachteile:

• Firestore ist kein Postgres und bietet keine SQL-Joins; komplexe relationale Abfragen erfordern oft eine Neugestaltung des Datenmodells, anstatt einfach andere SQL-Anweisungen zu schreiben
• Die HIPAA-Abdeckung gilt nur für eine bestimmte Liste von GCP-verwalteten Produkten; Firebase Authentication, Realtime Database und einige andere Firebase-Dienste sind ausdrücklich vom BAA ausgeschlossen
• Keine Option für Selbsthosting in der Produktivumgebung; der Firebase-Emulator ist nur für die lokale Entwicklung gedacht

3. Neon

Ein Spezialist für serverloses Postgres mit automatischer Skalierung der Rechenleistung und „Copy-on-Write“-Verzweigung, der eine Authentifizierungsschicht hinzufügt, ohne eine vollständige Backend-Plattform zu werden. 

Neon trennt Speicher von Rechenleistung, skaliert die Rechenleistung automatisch innerhalb eines konfigurierten Bereichs (bis zu 16 CU bei „Launch“ und „Scale“, wobei bei „Scale“ feste Größen bis zu 56 CU für konstante, hochbelastete Workloads verfügbar sind) und skaliert bei Inaktivität auf null. Lese-Replikate laufen als separate, automatisch skalierende Recheninstanzen auf demselben Speicher, und „Copy-on-Write“-Zweige liefern innerhalb von Sekunden eine vollständige, beschreibbare und isolierte Kopie einer Datenbank – nützlich sowohl für Vorschauen als auch zum sicheren Debuggen von Produktionsproblemen, ohne die Live-Daten zu berühren. Neon Auth (basierend auf Better Auth) speichert Benutzer und Sitzungen in der teameigenen Datenbank statt in einem Identitätsspeicher eines Drittanbieters. HIPAA ist ein Self-Service-Add-on im Scale-Tarif, neben SOC 2 Typ 1 und 2, SOC 3, ISO 27001, ISO 27701, DSGVO und CCPA.

Wichtigste Funktionen:

• Automatische Skalierung der Rechenleistung (bis zu 16 CU bei „Launch“ und „Scale“, feste Größen bis zu 56 CU bei „Scale“), mit Skalierung auf Null im Leerlauf
• Lese-Replikate, die sich unabhängig vom Primärserver automatisch skalieren, sowie „Copy-on-Write“-Zweige für isolierte, beschreibbare Datenbankkopien
• Neon Auth, bei dem Benutzer und Sitzungen in der teaminternen Datenbank statt in einem Identitätsspeicher eines Drittanbieters gespeichert werden
• HIPAA ist als Self-Service-Add-on im „Scale“-Tarif verfügbar, ebenso wie SOC 2, SOC 3, ISO 27001, ISO 27701, DSGVO und CCPA

Am 
besten geeignet für: Teams, die eine echte Elastizität bei der Rechenleistung und dem Speicherplatz von Postgres wünschen und kein Problem damit haben, ihre Anwendung sowie alle Auth-/Storage-/Realtime-Äquivalente jenseits von Neon Auth an einem anderen Ort zu hosten.

Vorteile:

• Automatische Rechenleistungsskalierung und „Scale-to-Zero“ sind das Kernprodukt von Neon, kein Add-on
• „Copy-on-Write“-Zweige dienen sowohl als Vorschauumgebungen als auch als sichere Möglichkeit, Produktionsdaten zu debuggen
• HIPAA ist bei Scale selbstverwaltbar, ohne dass ein separates Verkaufsgespräch mit dem Unternehmensvertrieb erforderlich ist, um es zu aktivieren.

Nachteile:

• Neon hostet weder Anwendungscode noch Worker und bietet auch keine Speicher- oder Echtzeit-Äquivalente an; dafür braucht ein Team eine separate Plattform.
• Die Data-API unterstützt derzeit keine Projekte, bei denen zusätzlich „IP Allow“ oder „Private Networking“ aktiviert sind, was sich auf die Zugriffsmöglichkeiten eines Teams auswirkt.

4. Upsun Cloud

Eine Multi-Cloud-Anwendungsplattform, auf der verwaltetes PostgreSQL oder MariaDB einer von mehreren erstklassigen Diensten ist und die Compliance sowohl die Anwendung als auch die Datenbank umfasst.

Upsun Cloud hostet Anwendungen auf AWS, GCP, Azure, OVHcloud und IBM Cloud, wobei verwaltete PostgreSQL- und MariaDB-Instanzen zwei von mehreren integrierten Diensten sind. Seit Juli 2026 skalieren PostgreSQL- und MariaDB-Lese-Replikate horizontal automatisch mit der Skalierung von Anwendungen und Workern – alles anhand derselben CPU- und Speicher-Trigger; die primäre Lese-Schreib-Datenbankinstanz wird weiterhin vertikal durch manuelle Konfiguration skaliert. Jeder Git-Zweig wird zu einer eigenen Umgebung, die aus ihrem übergeordneten Zweig geklont wird – zusammen mit echten Produktionsdaten, Apps und Diensten, nicht nur der Datenbank isoliert. Die Compliance-Standards – ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und DSGVO – gelten für die Plattform, auf der die Anwendung eines Teams läuft, und nicht für einen Datenbankdienst, der separat erworben wird, unabhängig davon, wo die Anwendung selbst gehostet wird.

Wichtigste Funktionen:

• Verwaltete PostgreSQL- und MariaDB-Instanzen mit automatisch skalierenden Lese-Replikaten, zusammen mit der automatischen Skalierung von Anwendungen und Workern anhand derselben Auslöser
• Multi-cloud-Bereitstellung über AWS, GCP, Azure, OVHcloud und IBM Cloud
• Umgebungen pro Zweigstelle, die Produktions-Apps, -Dienste und -Daten gemeinsam klonen
• Compliance (ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA, DSGVO), die sowohl die Anwendungsplattform als auch die Datenbank abdeckt

Am besten geeignet für: Teams, die eine echte, verwaltete Postgres- oder MariaDB-Instanz wollen, die zusammen mit ihrem eigenen Programmcode und ihren Workern auf einer Plattform läuft, wobei ein einziger Compliance-Umfang beides abdeckt – anstatt einen Datenbankanbieter, einen App-Host und eine Authentifizierungs- oder Speicherschicht separat zusammenzustellen.

Vorteile:

• Die Compliance gilt für den gesamten Stack, den ein Team betreibt, nicht nur für die Datenbank isoliert davon, wo auch immer die App gehostet wird
• Die automatische Skalierung der Datenbank-Lese-Replikate folgt dem gleichen Modell wie die automatische Skalierung von App und Workern und ist kein separates Produkt mit eigenen Regeln
• Durch die Multi-cloud-Option vermeidet man, die Entscheidung über Datenbank und Hosting an einen einzigen Anbieter zu binden

Nachteile:

• Keine integrierte Auth-, Storage- oder Realtime-API-Schicht; ein Team programmiert und hostet diese Logik im eigenen Anwendungscode, anstatt einen gebündelten Dienst aufzurufen
• Die automatische Skalierung der Datenbank umfasst Lese-Replikate; die primäre Schreibinstanz wird weiterhin vertikal durch manuelle Konfiguration skaliert

Ein Vergleich der vier Optionen

Die richtige Plattform auswählen

Die Entscheidung hängt von zwei Fragen ab: Benötigt die App ein gebündeltes Backend (Authentifizierung, Speicher, Echtzeit) oder nur eine Datenbank, und passen die Daten wirklich zu einem relationalen oder einem Dokumentenmodell? Supabase und Firebase beantworten die erste Frage mit „gebündeltes Backend inklusive“; Neon und Upsun Cloud antworten darauf mit „bring deine eigene Anwendungsschicht mit“.

Supabase ist die beste Wahl für ein Team, das eine vollständige Backend-as-a-Service-Plattform auf Basis von echtem Postgres will und damit leben kann, dass Lesevorgänge stärker skalieren als Schreibvorgänge. 

Firebase ist die beste Wahl, wenn die Daten wirklich zu einem Dokumentenmodell passen und multiregionale, stark konsistente Schreibvorgänge wichtiger sind als SQL, wobei die Compliance-Aspekte sorgfältig behandelt und nicht einfach vorausgesetzt werden. 

Neon ist die beste Wahl für ein Team, das sich eine echte Elastizität bei der Rechenleistung und dem Speicher von Postgres wünscht und seine Anwendung bereits anderweitig hostet. 

Upsun Cloud ist die beste Wahl für ein Team, das seine Anwendung, Worker und Postgres- oder MariaDB-Datenbank auf einer Plattform unter einem Compliance-Rahmen haben möchte, anstatt Datenbankanbieter und App-Host separat zusammenzustellen.

Häufig gestellte Fragen (FAQs)

Ist Firebase HIPAA-konform?

Nur teilweise und nur für bestimmte Produkte. Die HIPAA-Geschäftspartnervereinbarung von Google deckt eine namentlich aufgeführte Liste von abgedeckten Produkten ab, darunter Firestore (unter dem Namen Google Cloud), Cloud Storage, Identity Platform und Cloud Run-Funktionen. Firebase-Dienste außerhalb dieser Liste, darunter Firebase Authentication, Firebase Realtime Database, Firebase Hosting und Crashlytics, sind ausdrücklich nicht abgedeckt, selbst innerhalb desselben Projekts.

Unterstützt Supabase Schreibvorgänge über mehrere Regionen hinweg?

Nein. Supabase-Lese-Replikate, einschließlich regionenübergreifender Replikate ab der Pro-Stufe, skalieren nur Lesevorgänge. Schreibvorgänge bleiben auf der einzigen Primärinstanz, die vertikal skaliert (bis zu 64 Kerne und 256 GB), anstatt über Regionen verteilt zu werden.

Was ist der wesentliche Unterschied zwischen Neon und Supabase?

Beide stellen Standard-Postgres bereit, aber Supabase bündelt Auth, Storage, Realtime und Edge Functions zusätzlich zur Datenbank, während Neon ein eigenständiger Datenbankdienst ist, mit einer neueren, minimalistischeren Neon-Auth-Schicht anstelle einer vollständigen Backend-Plattform. Ein Team, das sich für Neon statt Supabase entscheidet, hostet seine Anwendung – und oft auch die Authentifizierung und den Speicher – in der Regel bereits an anderer Stelle.

Bietet Upsun Cloud integrierte Auth- oder Speicher-APIs wie Supabase oder Firebase an?

Nein. Upsun Cloud hostet die Anwendung, ihre Worker und eine verwaltete PostgreSQL- oder MariaDB-Datenbank auf einer Plattform, aber Authentifizierung, Dateispeicher und Echtzeitfunktionen sind Dinge, die ein Team im eigenen Anwendungscode programmiert, anstatt auf gebündelte Dienste zurückzugreifen.

Welche dieser vier Lösungen skaliert Schreibvorgänge in der Produktivumgebung am besten?

Firebases Firestore ist die einzige der vier Lösungen mit echter regionenübergreifender Skalierung bei Schreibvorgängen, da ihr Dokumentenmodell und die Paxos-basierte Replikation von Anfang an darauf ausgelegt sind. Supabase, Neon und Upsun Cloud führen alle Standard-Postgres oder MariaDB auf einer einzigen beschreibbaren Instanz aus; sie skalieren Lesevorgänge über Replikate und Rechenleistung durch vertikale Größenanpassung (im Fall von Neon und Upsun Cloud durch automatische Skalierung der Replikate), anstatt Schreibvorgänge über Regionen zu verteilen.

Kann ein Team Neon oder Upsun Cloud mit seinem eigenen Authentifizierungs- und Speicher-Stack nutzen?

Ja, und das entspricht eher der typischen Nutzungsweise beider Lösungen. Neon stellt die Datenbank bereit (plus optional „Neon Auth“ für eine schlankere Authentifizierungsschicht), und ein Team hostet seine Anwendung sowie jegliche zusätzliche Authentifizierungs-, Speicher- oder Dateiverarbeitungslogik auf einer separaten Plattform. Upsun Cloud hostet die Anwendung und die Worker direkt neben der Datenbank, sodass der eigene Authentifizierungs- und Speichercode eines Teams auf derselben Plattform läuft wie die Datenbank, mit der es verbunden ist, und nicht auf einem separaten Host.