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

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.