Benchmarks, die D1, PlanetScale und Neon vergleichen, neigen dazu, das Falsche zu messen. Latenz in Mikrosekunden, Durchsatz in Abfragen pro Sekunde, Ergebnisse synthetischer Abfragen – keine dieser Zahlen beantwortet die entscheidende Frage: Welche dieser drei Banken ist für das, was Sie gerade aufbauen, die richtige? Es gibt drei verschiedene Architekturen mit unterschiedlichen Kompromissen, keine Leistungsvarianten desselben Produkts.
D1: SQLite am Rande ohne Kosten für den Einstieg
Das zentrale Argument von D1 ist die native Integration mit Cloudflare Workers. Wenn ein Worker über eine Bindung auf eine D1-Datenbank zugreift, gibt es keinen TCP-Handshake, keine Verbindungszeichenfolge und keinen zu verwaltenden Verbindungspool. Die Abfrage geht direkt an die D1-Bindung im selben Laufzeitkontext, mit einer Latenzzeit von weniger als einer Millisekunde, um den Anruf aufzubauen. In einer serverlosen Architektur, in der jede Millisekunde Overhead zählt, ist diese Integration real und messbar.
Das kostenlose Kontingent bietet 5 GB Speicherplatz, 5 Millionen gelesene Zeilen pro Tag und 100.000 geschriebene Zeilen pro Tag – genug für Entwicklung, interne Tools und Prototypen mit geringem realen Datenverkehr. Beim kostenpflichtigen Plan: 0,001 $ pro Million gelesener Zeilen, 1 $ pro Million geschriebener Zeilen, 0,75 $/GB-Monat Speicher. Die lokale Entwicklung über wrangler dev --local erstellt eine echte SQLite-Datei auf dem Computer mit Verhaltensparität mit der Remote-Datenbank.
Die Grenzen, die definieren, wo D1 nicht sinnvoll ist: 2 GB pro Bank, 10 Banken im kostenpflichtigen Plan, keine benutzerdefinierten SQLite-Erweiterungen außer sqlite-vec für die Vektorsuche. Eine Bank, die über 2 GB hinaus wächst, hat innerhalb von D1 keinen Erweiterungspfad – Sie müssen die Daten aufteilen oder zu einer anderen Bank migrieren, bevor Sie das Limit erreichen. Für Anwendungen, die diese Obergrenze voraussichtlich überschreiten werden, ist D1 die richtige Bank für den Anfang und die falsche Bank für die langfristige Aufbewahrung.
PlanetScale: MySQL mit horizontalem Sharding und Schemaverzweigung
PlanetScale basiert auf Vitess – derselben Datenbank-Infrastruktur, die YouTubes MySQL auf Volumina skaliert hat, die Standard-MySQL nicht verarbeiten kann. Dieser Ursprung definiert, was PlanetScale bietet: echtes MySQL (die meisten ORMs funktionieren ohne Modifikation), plattformverwaltetes horizontales Sharding bei wachsender Datenmenge und der Schema-Branching-Workflow, der PlanetScale von allen anderen heute verfügbaren Datenbanken unterscheidet.
Die Schemaverzweigung funktioniert wie die Versionskontrolle für ein Schema: Sie erstellen einen Schemazweig, wenden die Änderungen an, testen und führen die Verzweigung wieder mit dem Hauptzweig zusammen. Die Migration läuft ohne Sperren von Tabellen – im Gegensatz zum MySQL-Standard ALTER TABLE, der Schreibvorgänge während der Ausführung sperrt. Für Teams, die mit Wartungsfenstern für Migrationen zu kämpfen haben oder Schemaänderungen sicher rückgängig machen müssen, löst diese Funktionalität ein echtes Problem.
Die Kosten sind der wichtigste Filter: PlanetScale hat das kostenlose Kontingent im Jahr 2024 eingestellt. Der Scaler-Plan beginnt bei 39 $/Monat. Für Nebenprojekte und Anwendungen im Frühstadium, bei denen es sich nicht um Einnahmen handelt, entfällt bei dieser Etage PlanetScale als Option. Für Produkte mit konstantem Umsatz und Teams mit MySQL-Erfahrung sind 39 US-Dollar pro Monat für das, was PlanetScale liefert, angemessen. Der richtige Vergleich ist nicht mit dem kostenlosen D1, sondern mit den Kosten für die manuelle Verwaltung des MySQL-Shardings, wenn das Volumen wächst.
Neon: Echtes PostgreSQL mit serverloser Datenverarbeitung
Neon liefert PostgreSQL – keine kompatible Teilmenge, kein SQLite mit einer MySQL-Schnittstelle, sondern die eigentliche Postgres-Laufzeitumgebung. Diese Unterscheidung ist wichtig, wenn das, was Sie benötigen, in keiner anderen Datenbank vorhanden ist serverlos: PostGIS für Geodaten, pg_trgm für die Fuzzy-Textsuche, pg_partman für die automatische Tabellenpartitionierung, TimescaleDB für Zeitreihen, komplexe Fensterfunktionen, die SQLite mit Einschränkungen ausführt.
Das serverlose Rechenmodell von Neon – das auf Null skaliert, wenn keine Abfragen vorliegen – bringt es in eine interessante Position für Anwendungen mit sporadischem Datenverkehr: Sie zahlen nur für die Rechenleistung, wenn aktiv auf die Datenbank zugegriffen wird. Der Pro-Plan kostet 19 US-Dollar pro Monat, inklusive 10 GB Speicher. Für Teams, die bereits über PostgreSQL-Code verfügen und eine serverlose Datenbank ohne Migration des SQL-Dialekts benötigen, ist Neon der direkteste Weg.
Der Nachteil im Vergleich zu D1 in einer Cloudflare Workers-Umgebung: Neon verwendet einen Verbindungspooler (Neon Proxy), auf den über die Standard-PostgreSQL-Verbindungszeichenfolge zugegriffen wird. Es gibt keine native Bindung wie bei D1. Die Latenz beim Herstellen der Verbindung zum Neon-Proxy hängt davon ab, welche Neon-Region Sie konfiguriert haben und wo der Worker ausgeführt wird. Sie kann je nach Topologie 10 ms oder 80 ms betragen, verglichen mit weniger als einer Millisekunde für D1.
Die Kosten der Migration zwischen den drei
Die Auswahl einer Datenbank zu Beginn eines Projekts ist mit impliziten Kosten verbunden, die nur dann auftreten, wenn die Auswahl falsch ist und Sie Änderungen vornehmen müssen. Die drei Banken haben asymmetrische Migrationskosten.
Der Wechsel von D1 zu Neon ist technisch machbar, aber nicht trivial: wrangler d1 export generiert einen SQL-Dump im SQLite-Dialekt, der vor dem Import in PostgreSQL konvertiert werden muss. Die meisten Abfragen werden unterstützt, aber bestimmte SQLite-Verhaltensweisen – wie Typaffinität, die Semantik von AUTOINCREMENT gegenüber SERIAL, die Handhabung von Datumsangaben – müssen von Fall zu Fall überprüft werden. Der Umfang der Anpassungen hängt davon ab, inwieweit der Code die Besonderheiten von SQLite ausnutzt.
Der Wechsel von PlanetScale zu einer anderen Datenbank bedeutet den Wechsel von MySQL zu SQLite (D1) oder PostgreSQL (Neon) – verschiedene Dialekte mit genügend Syntaxunterschieden, die einen echten Portierungsaufwand erfordern. Wenn der Code Transaktionen mit MySQL-spezifischer Syntax, MySQL-String-Funktionen oder anderen proprietären Funktionen verwendet, ist die Migration teurer.
Die Regel, die die Entscheidung vereinfacht: Wenn Sie Cloudflare Workers nutzen und Ihre Daten in weniger als 2 GB passen, ist D1 die richtige Standardeinstellung. Wenn Sie PostgreSQL von Anfang an benötigen – für Erweiterungen, für die Kompatibilität mit vorhandenen Tools, für Abfragen, die SQLite nicht gut unterstützt – beginnen Sie mit Neon, anstatt später zu migrieren. PlanetScale kommt ins Spiel, wenn die horizontale Skalierung von Vitess erforderlich ist und nicht der Eintrittspreis. Keine der drei Lösungen löst analytische Arbeitslasten gut – hierfür ist die Cloudflare Analytics Engine oder eine spezielle OLAP-Datenbank der kürzeste Weg.
Lesen Sie auch
- Email Routing vs. Improvmx vs. Forward Email: ehrlicher Vergleich
- Arbeiter + D1 + KV + R2: Zusammenstellen von Bindungen im selben Dienst
- DNS-Proxy vs. nur DNS: Was ändert sich und wann macht jeder Modus Sinn
- KV vs. R2 vs. Cache-API: Wann die einzelnen Cloudflare-Speicherstufen verwendet werden sollten
- Cloudflare D1: Die SQLite-Datenbank am Rande – und warum „Edge“ nicht das bedeutet, was es scheint
- Cloudflare Load Balancing und Geo Steering: Wenn DNS zu einer intelligenten Verkehrsschicht wird