Neon, Turso, D1, Durable Objects, Vectorize – wie sich die Datenschicht für Cloudflare-nahe Architekturen zusammensetzt
Der neue Trend ist nicht „Postgres ablösen”. Der neue Trend ist, Postgres mit edge-tauglicher Anbindung, zusätzlicher Replikation und AI-nahen Spezialkomponenten zu kombinieren. Für Cloudflare-nahe Architekturen ist das deutlich relevanter als die alte Frage „SQL oder MongoDB?”.
Cloudflare selbst pusht genau in diese Richtung: Workers, Hyperdrive, Durable Objects, D1, Vectorize und Workflows greifen inzwischen sauber ineinander. Hyperdrive ist seit April 2025 auf dem Free-Plan verfügbar; D1 hat globale Read Replication bekommen; SQLite-backed Durable Objects sind seit April 2025 GA und werden von Cloudflare ausdrücklich für neue stateful Patterns empfohlen.
Für die meisten Szenarien liegt der Fokus auf drei Ebenen:
- Postgres als Standard-Kern – relationale Daten, ORM-Kompatibilität, Reporting, Migrationen
- SQLite/libSQL für edge-nahe Workloads – leichtgewichtig, repliziert, nah am Nutzer
- Spezialstores für AI – Vector Search, zustandsbehaftete Workflow-/Agent-State-Patterns
Neon + Postgres + Hyperdrive: Der evolutionäre Standardweg
Wer bei einem Standard bleiben will, ist mit Neon plus Cloudflare Hyperdrive derzeit auf einem der stärksten Wege. Neon positioniert sich klar als Serverless-Postgres für solche Deployments, und die offizielle Cloudflare-Dokumentation empfiehlt entweder Hyperdrive oder den Neon Serverless Driver – mit Hyperdrive als bevorzugtem Weg wegen Connection Pooling und niedriger Latenz.
Das eigentliche Problem bei Postgres an der Edge ist oft nicht Postgres selbst, sondern Verbindungsmanagement, Kaltstarts, TCP/TLS-Setup und regionale Distanz. Neon + Hyperdrive adressiert genau das, ohne dass Datenmodell oder SQL-Know-how aufgegeben werden müssen. Cloudflare verlagert den teuren DB-Handshake an den Edge und spart so Latenz.
Für Standards, ORM-Kompatibilität, Reporting, relationale Daten, Mandantenmodelle und saubere Migrationen ist das die vernünftigste Default-Entscheidung. Eher der beste evolutionäre Weg als eine „neue DB-Revolution”.
Turso / libSQL: Die spannendste neue Entwicklung
Die interessanteste Bewegung im Datenbank-Bereich ist aus meiner Sicht Turso mit libSQL. Der Stack ist ausdrücklich mit Cloudflare Workers, Vercel Edge Functions und anderen Edge-Runtimes kompatibel. Turso hat 2025 sein größeres Rework als „next evolution of SQLite” vorgestellt – mit Fokus auf Async-APIs, bessere Concurrency und native Vector Search. Exakt die Punkte, an denen klassisches SQLite in modernen AI-/Edge-Workloads schwächelt.
Für viele AI-Workflows braucht man gar nicht immer einen großen zentralen Postgres-Cluster, sondern eher:
- Schnelle Reads nah am Nutzer
- Leichtgewichtige Speicherung für Agent-Memory, Session-State, Tool-Logs, Caches, Per-Tenant-Daten
- Eine SQL-nahe API ohne schweres Betriebsmodell
Genau da passt Turso/libSQL sehr gut. Nicht unbedingt als kompletter Postgres-Ersatz, aber als ernsthafte Ergänzung – oder für bestimmte Produktklassen sogar als Primär-DB.
Cloudflare D1: Besser als sein Ruf, aber mit Grenzen
D1 ist heute deutlich ernster zu nehmen als noch vor einem Jahr. Cloudflare beschreibt D1 als Serverless-SQL-Datenbank mit SQLite-Semantik; zuletzt kamen globale Read Replication und klarere Abgrenzungen zu Durable Objects dazu. D1 eignet sich besonders für viele kleinere Datenbanken und horizontale Aufteilung.
Trotzdem wäre Vorsicht geboten, D1 als alleinigen Master Store für alles einzusetzen. D1 ist Cloudflare-nativ und praktisch, aber weniger Standard als Postgres. Man bleibt näher an SQLite/D1-spezifischen Mustern und weiter weg vom großen Postgres-Ökosystem.
Wo D1 passt: Edge-nahe Web-Apps, Content-lastige Tools, Read-heavy APIs, Tenant-weise kleine Datenbanken.
Wo Postgres stärker bleibt: Komplexe Business-Logik, umfangreiche SQL-Funktionen, BI-lastige Auswertung, maximale Portabilität.
D1 ist für Cloudflare-zentrische Produkte gut, aber für einen „Weg zu Standards” eher ergänzend als strategischer Hauptanker.
SQLite-backed Durable Objects: Die neue Architekturkomponente
Das ist keine klassische externe Datenbank, aber für AI-nahe Edge-Systeme gerade sehr wichtig. SQLite-backed Durable Objects sind seit April 2025 GA. Cloudflare empfiehlt sie für neue stateful Patterns: Chat, Agent-State, Collaboration, Echtzeit-Interaktionen, Pro-Entity-State. Sie unterstützen SQL, KV-Methoden und Point-in-Time Recovery.
Für AI-Workflows ist das spannend, weil viele Agenten- oder Workflow-Prozesse nicht nur Daten speichern, sondern koordinierten, konsistenten Zustand brauchen: Laufende Sessions, Job-Orchestrierung, Locks, Human-in-the-Loop-Schritte, Thread-Memory, Stream-State. In solchen Fällen ist ein Durable Object oft passender als eine normale DB-Tabelle.
Zusammen mit Cloudflare Workflows entsteht ein schlüssiges Betriebsmodell für langlebige AI-Prozesse. Nicht das relationale Hauptsystem – aber eine Architekturkomponente, die praktisch unverzichtbar wird.
Was AI-Workflows von der Datenschicht brauchen
Für AI-Systeme braucht man typischerweise mehr als eine einzige Datenbankrolle:
| Rolle | Anforderung | Empfehlung |
|---|---|---|
| System of Record | Klassische relationale Daten | Postgres (Neon/Supabase) |
| Agent/Session/Workflow-State | Koordinierter Edge-State | Durable Objects, Turso |
| Semantische Suche / RAG | Vektorsuche | Vectorize, pgvector |
| Blob/Artefakte | Objektstorage | R2 |
Diese Trennung ist in den aktuellen Plattformen immer sichtbarer geworden. Cloudflare positioniert Workflows ausdrücklich für langlebige AI-Abläufe, und Vectorize ist ihr global verteilter Vektorstore für Workers.
Die richtige Frage ist heute nicht mehr „Welche eine Datenbank nehme ich?”, sondern: Welche Kombination aus relationalem Kern, Edge-State und Vektor-Layer erzeugt am wenigsten Reibung?
Supabase: Weiterhin im Rennen
Supabase ist keineswegs überholt. Im Gegenteil: In den letzten 12 Monaten gab es Automatic Embeddings, stärkere Patterns für Background Tasks in Edge Functions und explizite Anleitungen für ChatGPT-/MCP-nahe Apps. Der Stack entwickelt sich klar in Richtung AI-fähige Standardplattform.
Der Haken: Supabase ist nicht so Cloudflare-zentriert wie Neon + Hyperdrive oder D1/DO. Es lässt sich mit Cloudflare kombinieren, aber das fühlt sich architektonisch nicht ganz so direkt an. Wer bereits gut mit Supabase/Postgres arbeitet, hat weiterhin eine sehr vernünftige Wahl – es ist nur nicht die „neueste Edge-Story”, sondern eher der robuste Postgres-Komplettstack.
MongoDB: Nur unter bestimmten Bedingungen
MongoDB ist nicht weg, aber für Cloudflare-nahe Standardarchitekturen keine erste Wahl. Atlas Vector Search erlaubt, Vektoren und operative Daten zusammen zu halten – inklusive Hybrid Search, Filtern und Generative-AI-Use-Cases. Technisch stark.
Aber: Für den Fokus „Standards öffnen”, „Cloudflare harmoniert gut”, „einfach standardisiert Dinge ablegen” ist MongoDB nicht der klarste Weg. Viele AI-/Workflow-/B2B-Systeme landen am Ende bei relationalen Anforderungen, klaren Joins, SQL-Analysen, Migrationssicherheit und Reportability. Da fährt Postgres ruhiger. MongoDB wählen, wenn das Datenmodell wirklich dokumentenlastig ist oder gezielt dessen Such-/Atlas-Ökosystem genutzt werden soll.
Die stärksten Signale der letzten 12 Monate
Edge-kompatibles Postgres wird reifer. Nicht Postgres verschwindet, sondern die Infrastruktur darum wird edge-tauglicher. Neon + Hyperdrive ist das sauberste Beispiel.
SQLite erlebt ein echtes Comeback – in neuer Form. Nicht als lokale Bastellösung, sondern als replizierte, serverless, edge-kompatible SQL-Basis. D1, Durable Objects mit SQLite und Turso/libSQL zeigen genau das.
AI braucht eigene Speicherschichten. Vectorize, Supabase Vector/Automatic Embeddings und MongoDB Vector Search zeigen, dass Vektor- und Retrieval-Layer inzwischen Standardbausteine sind, nicht nur Add-ons.
Workflow-State wird wichtiger als früher. Mit Cloudflare Workflows und Durable Objects verschiebt sich ein Teil dessen, was man früher nur in klassischen Datenbanken modelliert hätte, in zustandsbehaftete Laufzeitkomponenten. Für AI-Agenten ist das besonders relevant.
Drei Stack-Varianten im Vergleich
Konservativ: Postgres-zentrisch
- Datenbank: Neon Postgres + Hyperdrive
- Vector: pgvector (in Postgres)
- State: Postgres-Tabellen, ggf. Redis
- Storage: R2
- Vorteil: Ein System, ein Ökosystem, maximale Portabilität
- Nachteil: Höhere Latenz bei globalen Reads, kein Edge-State
Modern: Edge-first mit Ergänzungen
- Datenbank: Neon Postgres + Hyperdrive (Kern) + Turso/libSQL (Edge-Reads)
- Vector: Vectorize (Cloudflare)
- State: Durable Objects (SQLite-backed)
- Storage: R2
- Vorteil: Niedrige Latenz global, saubere Trennung der Rollen
- Nachteil: Mehr bewegliche Teile, zwei SQL-Dialekte
Maximal Cloudflare-nativ
- Datenbank: D1 (Kern) + Durable Objects (State)
- Vector: Vectorize
- State: Durable Objects + Workflows
- Storage: R2
- Vorteil: Minimale externe Abhängigkeiten, tiefe Workers-Integration
- Nachteil: Vendor Lock-in, weniger SQL-Funktionsumfang, begrenzte Portabilität
Unterm Strich
Der Standard-Weg ist nicht „weg von Postgres”, sondern Postgres plus edge-taugliche Infrastruktur.
Die eigentliche neue Technologie, auf die man achten sollte, ist libSQL/Turso.
Und die eigentliche neue Architekturentscheidung ist, State, Workflow und Vector getrennt zu denken – statt alles in eine einzige Hauptdatenbank zu pressen.
Weiterführende Artikel
- PostgreSQL: Von der relationalen Datenbank zur Plattform – Wie Postgres durch Extensions zum universellen Datenbank-Betriebssystem wird
- Weniger Tools, mehr Postgres – Ein Survival-Guide für Backend-Vereinfachung
- Welche lokale Datenbank passt zu deiner App? – Praxisnaher Überblick für Mobile, Desktop, Web und Edge