Spielt es eine Rolle, welche, wenn alle Postgres sind?

Zwei der vier sind es nicht, und unter denen, die es sind, unterscheidet sich, was zwischen Ihnen und der Engine steht. Eine Plattform, die shardet, oder Speicher von Compute trennt, oder einen Pooler in den Pfad setzt, erlegt jeweils dem Schema oder dem Transaktionsmodell etwas auf. Vergleichen Sie das, nicht die Marketingseiten.

Welche ist die günstigste?

Die, die zu Ihrer Verkehrsform passt, und die Antwort kehrt sich um. Stoßweiser Verkehr mit langen ruhigen Phasen ist das, wofür Scale-to-Zero-Preise gedacht sind. Stetiger Verkehr ist das, wofür eine feste Instanz gedacht ist, und je Anfrage für stetigen Verkehr zu zahlen ist die teuerste Art, eine kleine Datenbank zu betreiben.

Brauchen wir überhaupt eine Plattform?

Nein. Eine verwaltete Postgres-Instanz von irgendeinem Cloud-Anbieter arbeitet perfekt mit Next.js und ist häufig die günstigere, vorhersehbarere Wahl. Was die Plattformen darüber hinaus verkaufen, sind Branching, ein HTTP-Treiber und ein integrierter Pooler - echtes Geld wert, wenn Sie sie nutzen, nichts wert, wenn nicht.

Die Funktionen, die nicht Postgres sind. Auth, Storage, Realtime, Row-Level-Security-Policies, die im Modell der Plattform geschrieben sind, und jede Client-Bibliothek, die die Datenbank umhüllt statt mit ihr zu sprechen. Das Postgres darunter ist portabel; die Oberfläche, gegen die Sie gebaut haben, vielleicht nicht.

Eine Datenbank für Next.js wählen: vier Plattformen

Vier Plattformen mit wirklich verschiedenen Modellen darunter. Was jede tatsächlich verkauft, und die Einschränkung in jeder, die Ihr Schema erreicht statt Ihrer Konfiguration.

Veröffentlicht am 21. September 20264 Min. LesezeitAktualisiert am 23. September 2026

Die vier Namen im Titel sind nicht vier Marken derselben Sache. Unter jedem steckt eine andere Entscheidung darüber, wo die Daten liegen und was davor sitzt, und diese Entscheidungen erreichen Ihren Code.

Hier ist, was jede tatsächlich verkauft, und wo es durchscheint.

Neon: Postgres mit Speicher getrennt von Compute

Das Unterscheidende ist nicht die Serverless-Preisgestaltung. Es ist, dass die Speicherschicht vom Compute getrennt ist, was einen Datenbank-Branch zu einer Copy-on-Write-Operation macht statt zu Dump und Restore.

Was das bringt. Ein Branch je Pull Request, in Produktionsdatengröße, in Sekunden. Migrationen im CI gegen echte Zeilenzahlen geprüft statt gegen eine Tabelle mit vierzig Zeilen. Für ein Team, dessen Migration sich in Produktion je anders verhalten hat, ist das die Funktion, für die zu zahlen sich lohnt.

Worauf zu achten ist. Compute suspendiert im Leerlauf, was eine Ersparnis ist, wenn Ihr Verkehr wirklich ruhige Phasen hat, und ein Kaltstart, wenn nicht. Und alles, was die Datenbank getaktet abfragt, hält sie wach - die Ersparnis ist also leicht unbemerkt zu verlieren.

Der HTTP-Treiber ist der andere Grund, warum sie in Next.js-Gesprächen auftaucht: er nimmt Connection Pooling für einfache Lesepfade als Problem heraus, mit den Vorbehalten einmaliger Abfragen.

Supabase: Postgres plus das Drumherum

Supabase ist ein echtes Postgres mit Auth, Objektspeicher, Realtime-Abonnements und einer automatisch erzeugten API darüber. Der Vergleich handelt nur zum Teil von der Datenbank.

Was das bringt. Wenn Sie ohnehin Authentifizierung und Dateispeicher brauchen, ist es eine echte Ersparnis, wenn sie ein Identitätsmodell mit Ihren Daten teilen - und Row Level Security heißt, dass eine Autorisierungsregel in der Datenbank leben kann, statt in jeder Route neu geschrieben zu werden, die die Tabelle anfasst.

Worauf zu achten ist. RLS ist mächtig und es ist ein zweiter Ort, an dem Autorisierung lebt. Eine Policy, die subtil falsch ist, scheitert offen, und sie ist in Ihrem Anwendungscode nicht sichtbar. Was Sie auch übernehmen, übernehmen Sie es bewusst: entweder besitzt die Datenbank die Zugriffskontrolle oder die Anwendung, und beides zu haben ist, wie die zwei sich widersprechen.

Nutzen Sie es nur als Postgres-Host, vergleichen Sie es als solchen. Der Großteil seines Werts liegt in dem, was Sie sonst selbst bauen würden.

PlanetScale: MySQL, darunter geshardet

Vitess unter der Haube, die Technologie, die großen MySQL-Installationen horizontales Skalieren ermöglichte. Die nach außen sichtbare Funktion ist ein Schema-Workflow: Branches und Deploy Requests, mit Schemaänderungen ohne Sperren.

Was das bringt. Nicht blockierende Schemaänderungen auf sehr großen Tabellen, ein echtes und schwieriges Problem, richtig gelöst. Und ein Review-Ablauf für Schema, der aussieht wie der, den Sie für Code schon nutzen.

Worauf zu achten ist. Das Sharding-Modell ist der Grund, warum die Unterstützung für Fremdschlüssel ein bewegliches Ziel war - referenzielle Integrität über Shards hinweg ist wirklich teuer, und was unterstützt wird, hat sich über die Zeit geändert. Prüfen Sie das aktuelle Verhalten, bevor Sie sich darauf verlassen. Ein Fremdschlüssel, der akzeptiert und nicht durchgesetzt wird, ist schlimmer als einer, der abgelehnt wird, denn Ihre Anwendung glaubt etwas, das die Datenbank nicht tut.

Es ist außerdem MySQL: will Ihr Schema jsonb, partielle Indizes oder Erweiterungen, ist es die falsche Liste.

Turso: SQLite, verteilt

SQLite als Dienst, in Regionen nahe Ihren Nutzern repliziert, über HTTP angesprochen.

Was das bringt. Sehr niedrige Leselatenz von überall, weil der Lesezugriff lokal ist statt einen Ozean zu queren. Und die betriebliche Einfachheit von SQLite mit der Haltbarkeitsgeschichte, die Sie sonst selbst bauen müssten.

Worauf zu achten ist. Schreibzugriffe gehen an einen Primary, ein Schreibvorgang ist also nicht lokal und das Latenzprofil asymmetrisch. Und es ist SQLite - lose Typisierung, ein anderer Funktionsumfang und ein Nebenläufigkeitsmodell um einen Schreiber herum. Für leselastige Daten mit kleinem Schreibpfad ist es ausgezeichnet. Für eine transaktionale Anwendung mit umkämpften Schreibzugriffen ist es die falsche Form.

Wählen ohne Tabellenkalkulation

Beantworten Sie drei Fragen, und die Liste verkleinert sich von selbst.

Will Ihr Schema Postgres-Funktionen? JSON, das Sie abfragen werden, partielle Indizes, Check Constraints, Erweiterungen, PostGIS. Wenn ja, fallen zwei der vier sofort weg, und damit ist der größte Teil entschieden.

Ist Ihr Verkehr stoßweise oder stetig? Wirklich stoßweise - eine Kampagne, ein saisonales Produkt, ein B2B-Werkzeug, das am Wochenende niemand anfasst - ist das, wofür verbrauchsabhängige Preise da sind. Stetiger Verkehr auf einer festen Instanz ist fast immer günstiger und für viele Anwendungen die unmodische richtige Antwort.

Kaufen Sie eine Datenbank oder ein Backend? Stehen Auth, Storage und Realtime ohnehin auf Ihrer Liste, ist eine Plattform, die sie mitbringt, ein anderes und besseres Geschäft als eine Datenbank plus drei Dienste. Stehen sie nicht darauf, vergleichen Sie Postgres-Hosts.

Der Teil, der nicht die Datenbank ist

Was Sie auch wählen, die Next.js-spezifische Arbeit ist dieselbe: ein Client je Modulbereich, der gepoolte Endpunkt für Anfragen und der direkte für Migrationen, und eine Entscheidung darüber, wo Abfragen liegen. Das kostet einen Nachmittag und bestimmt, ob sich die Plattform gut verhält.

Den perfekten Anbieter zu wählen und einen Client in einem Route Handler zu erzeugen bringt Ihnen einen Verbindungslimit-Fehler auf einer sehr gut konstruierten Datenbank.

Steht die Datenbank fest, ist die nächste Entscheidung die Schicht darüber, und Prisma und Drizzle beantworten sie unterschiedlich genug, dass es zählt.

Ist die Datenbank nicht das führende System, sondern eine Kopie davon - ein Buchhaltungs- oder ERP-System, das etwas anderes hineinsynchronisiert -, ändern sich die Entscheidungen erneut, und das Alter der Daten wird zu einem Feld statt zu einer Cache-Einstellung.