Neon oder Supabase: 32 ms Gleichstand, doch Provisionierung trennt sie

Für häufige Datenbank-Branches und kurzlebige Vorschauumgebungen spricht vor allem Neon; für ein Backend, das Datenbank, Anmeldung, Dateien und Live-Updates zusammenführt, Supabase. Im Frankfurter Benchmark vom Juni 2026 erreichten beide Plattformen rund 32 ms mediane Latenz für einen einfachen Verbindungs- und Abfragezyklus. Vom Anlegen eines neuen Projekts bis zur ersten SQL-Abfrage vergingen in den getesteten Tarifen dagegen 5,5 Sekunden bei Neon und 111,9 Sekunden bei Supabase.

Der Zeitunterschied betrifft die Bereitstellung eines neuen Projekts, nicht jede spätere Abfrage. Welche Plattform besser passt, hängt deshalb davon ab, wie oft ein Team Umgebungen erzeugt, welchen Datenzustand sie benötigen und ob außer PostgreSQL weitere Backend-Dienste im selben Projekt laufen sollen. Für Softwareteams mit bevorzugter EU-Region ist das eine andere Entscheidung als die Wahl nach einem einzelnen Latenzwert.

Was der Latenzgleichstand aussagt

Gemessen wurde ein Verbindungsaufbau mit TLS und Authentifizierung, gefolgt von einer einfachen SQL-Abfrage. Die Datenbanken liefen in AWS eu-central-1, der Testclient in Frankfurt. Gleiche Region und kurze Netzwege machen die Messung für einen regionalen Vergleich brauchbar; sie bilden aber keine vollständige Anwendung mit deren Abfragen, Datenmengen und Verbindungsmustern ab.

Auch die Bereitstellungszeit hat eine präzise Grenze: Die Uhr lief bis zu dem Moment, in dem ein frisch angelegtes Projekt SQL beantwortete. Sie misst weder das Einspielen von Anwendungsdaten noch die Einrichtung zusätzlicher Dienste. Wer nur selten ein Produktionsprojekt erstellt, spürt diesen Unterschied weniger als ein Team, das Umgebungen für Pull Requests automatisiert erzeugt. Bei einer dauerhaft laufenden Anwendung werden dagegen Abfragepläne, Indizes, gleichzeitige Verbindungen und die Entfernung zum Anwendungsserver wichtiger.

Branches beginnen mit unterschiedlichem Datenzustand

Neon verzweigt den Zustand einer PostgreSQL-Datenbank. Ein Branch übernimmt zunächst Schema und Daten seines Elternbranches, bleibt für Änderungen aber isoliert. Der Neon-Leitfaden zum Branching beschreibt gemeinsam genutzte Ausgangsdaten und zusätzlichen Speicher für Änderungen; der Branch erhält eigene Rechenleistung, die bei Inaktivität auf null skalieren kann. So kann ein Test gegen einen bereits vorhandenen Datenbestand laufen, ohne ihn für jede Vorschau vollständig zu duplizieren.

Das erleichtert Tests mit realistischen Tabellen und Datenbeziehungen. Enthält der Elternbranch personenbezogene oder vertrauliche Informationen, gelangen diese allerdings zunächst ebenfalls in den neuen Branch. Für solche Fälle bietet Neon einen Branch nur mit Schema an; alternativ kann ein vorbereiteter, bereinigter Datenbestand als Ausgangspunkt dienen. Die Wahl des Elternbranches ist damit auch eine Entscheidung über den Inhalt der Testumgebung.

Ein Supabase-Preview-Branch ist eine eigene Umgebung mit Diensten und Zugangsdaten, beginnt standardmäßig jedoch ohne Daten und Storage-Objekte des Basisprojekts. Seine Datenbankstruktur entsteht bei einer GitHub-Anbindung aus Migrationen im Repository, bei Erstellung im Dashboard aus der Migrationshistorie. Testdaten lassen sich über Seed-Dateien ergänzen; im Dashboard gibt es außerdem eine Option zum Einbeziehen von Daten. Damit kann der Branch mehr vom gesamten Backend abbilden, verlangt für datennahe Tests aber einen bewusst eingerichteten Datenbestand.

Skalierung und Backend-Dienste im Betrieb

Neons Trennung von Speicherung und Rechenleistung ist besonders für unregelmäßig genutzte Datenbanken interessant. Wenn ein Vorschau-Branch ruht, kann seine Rechenleistung pausieren und bei der nächsten Verbindung wieder starten. Diese erste Anfrage braucht dann länger als eine Anfrage an bereits aktive Rechenleistung. Für einen Dienst mit engen Antwortzeitvorgaben zählt deshalb auch, ob die Datenbank durchgehend aktiv bleiben soll.

Supabase ordnet jedem Projekt eigene Datenbankressourcen zu. Die Supabase-Abrechnungsübersicht beschreibt ein Projekt als dedizierte Instanz mit Auth, Storage, Functions und Realtime; Rechenleistung wird je Projekt erfasst, während das Egress-Kontingent Datenverkehr aus mehreren Diensten umfasst. Für ein Web- oder App-Backend kann diese Bündelung die Integration vereinfachen, wenn Anmeldung, Dateiablage und Live-Updates tatsächlich gebraucht werden.

Für eine datenintensive Anwendung ist weder die Bereitstellungszeit noch die einfache Testabfrage ein ausreichendes Leistungsmaß. Lange Analysen, viele gleichzeitige Schreibvorgänge und ein großer aktiver Datenbestand beanspruchen Rechenleistung und Speicher anders. Hier entscheidet das erwartete Lastprofil: Neon erlaubt eine andere Zuordnung und Skalierung von Rechenleistung, während Supabase mit einer gewählten Projektgröße und gemeinsam betriebenen Diensten kalkuliert wird.

Wie viele Vorschauen die Rechnung verändern

Bei Neon wirken sich aktive Rechenzeit und Datenänderungen eines Branches auf das Kostenprofil aus. Viele kurzlebige Vorschauen, die überwiegend ruhen und wenig schreiben, nutzen die Trennung von Speicher und Rechenleistung besonders gut. Bleiben Branches dauerhaft aktiv oder verändern große Datenmengen, schrumpft dieser Vorteil. Entscheidend ist daher die tatsächliche Lebensdauer einer Umgebung, nicht allein die Zahl ihrer Erstellungsvorgänge.

Supabase berechnet für Preview-Branches verbrauchte Ressourcen der separaten Umgebung, darunter Rechenzeit, Datenbankspeicher, Storage und Egress. Für einen Preview-Branch fällt keine feste Branch-Gebühr an; seine Rechenzeit wird gesondert ausgewiesen und nicht durch das Compute-Guthaben des Hauptprojekts gedeckt. Die Nutzung zählt teilweise zu den Kontingenten des Abonnements. Zusätzliche Umgebungen können deshalb auch dann Kosten erzeugen, wenn sie nur als Vorschau dienen.

Für die Kalkulation sind ein produktives Projekt, die gleichzeitig offenen Vorschauen, deren Laufzeit, benötigte Testdaten und der Datenverkehr zusammen zu betrachten. Ein Einstiegspreis pro Tarif erfasst diesen Unterschied nur unvollständig: Auf der einen Seite stehen Datenbank-Branches mit potenziell ruhender Rechenleistung, auf der anderen komplette Backend-Umgebungen mit eigenen Ressourcen und mehreren nutzbaren Diensten.

Welche Wahl zum Projekt passt

Neon ist die stärkere Ausgangsbasis, wenn viele Pull Requests jeweils einen beschreibbaren PostgreSQL-Zustand benötigen und andere Backend-Funktionen bereits gelöst sind. Das gilt besonders für automatisierte Tests, bei denen neue Datenbankzustände häufig entstehen und wieder verschwinden. Der übernommene Datenbestand ist dabei nützlich, sofern er für die jeweiligen Testumgebungen geeignet ist.

Supabase passt besser, wenn das Team ein gemeinsames Backend für Datenbank, Anmeldung, Dateien und Live-Updates aufbauen möchte. Seine Branches können Änderungen an diesem Verbund abbilden, beginnen für Tests aber standardmäßig ohne Produktionsdaten. Bei hoher Dauerlast sollten beide Angebote anhand derselben Anwendungsabfragen und einer passenden EU-Region beurteilt werden: Die gemessene einfache Abfrage sagt wenig über die Kapazität eines konkreten Systems aus.

Lesen Sie auch:

• Substack oder Patreon: Die gleiche Provision, aber ein anderer Engpass
• Gumroad oder Payhip: Bei 100 Euro kostet der Unterschied mehr als fünf Euro
• GPT-6.1 Sol kostet ein Fünftel von Astra – der Sicherheitsrang bleibt gleich