Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich betreibe D1 in acht Produktions-SaaS-Apps, Neon in zwei Produktions-B2B-Apps und habe mit Cloudflare Durable Objects, Turso/libSQL und Supabase in kleineren Projekten ausgeliefert. Dieser Artikel ist der ehrliche Vergleich, den ich mir gewünscht hätte — Stärken zuerst genannt, dann wo jedes Option verliert, mit einer Entscheidungsmatrix am Ende. Kein Vendor-Sponsoring; jede Aussage stammt aus einem Production Trace.

Verifizierte Quellen: Cloudflare D1 Documentation · D1 Best Practices · D1 Limits · Neon Serverless Postgres · Supabase Documentation · Turso / libSQL · Cloudflare Durable Objects · SQLite Query Planner · Workers Analytics Engine · TanStack Ship Database Guide

Zuletzt aktualisiert: 2026-09-11 · Changelog

TL;DR: Für eine Workers-native, leseLastige SaaS im Jahr 2026 ist D1 der richtige Default — Sub-Millisekunden-Reads von regionalen Replicas, kein Connection Pool, SQLite Query Planner, eine einzige Abrechnungszeile. Die ehrlichen Alternativen: Neon (Serverless Postgres, wenn Sie JSONB und LISTEN/NOTIFY brauchen), Supabase (Postgres + Auth + Storage im Bundle), Turso/libSQL (libSQLs Multi-Region-Edge, wenn D1s Replikations-Topologie nicht passt) und Cloudflare Durable Objects (Per-Entity-State für Echtzeit-Koordination). Dieser Artikel vergleicht jede Option auf ihrer stärksten Achse, benennt wo sie verliert, und endet mit einer Entscheidungsmatrix. Wenn Sie zuerst den Performance-Deep-Dive wollen: D1-Performance-Benchmark-Post; für die Production Patterns: D1 Production Guide.

Cloudflare D1 vs Alternativen für die Produktion: Ein ehrlicher 2026er Vergleich

Die Frage „die beste Datenbank für eine SaaS 2026" hat keine einzige Antwort, aber wenige ehrliche. Cloudflare D1 ist eine davon; Neon, Supabase, Turso und Cloudflare Durable Objects sind die anderen, mit denen ich ausgeliefert habe. Jede Alternative wird auf ihrer stärksten Achse anerkannt, dann wo sie tatsächlich verliert, mit einer Entscheidungsmatrix am Ende.

Die Produktions-Datenbank-Entscheidung 2026

Drei Kräfte haben die Datenbank-Landschaft für Solo-SaaS-Entwickler in den letzten drei Jahren umgeformt. Edge-Runtimes — Cloudflare Workers, Vercel Edge, Deno Deploy — haben Compute nah an die Nutzer gebracht. Serverless Postgres — Neon, Supabase, PlanetScale — hat die Entscheidung „eine 40-$-Postgres-VM provisionieren" durch nutzungsbasierte Preise ersetzt. SQLite ist zu einem Distributed-Systems-Primitiv geworden, mit libSQL und D1, die eine Single-File-Engine in eine global replizierte Datenbank verwandeln.

Für einen SaaS-Gründer ist die praktische Konsequenz: Die Datenbankwahl dreht sich nicht mehr darum, welche Engine „am besten" ist, sondern welcher Trade-off zur Form Ihrer App passt.

Cloudflare D1: Die Edge-SQLite-Wette

Die Form eines D1-Schemas ist der SQLite-Dialekt, den jeder Entwickler kennt — INTEGER PRIMARY KEY, TEXT, Partial Indexes. Die Datenbank lebt am Edge und wird für Sie repliziert.

sql

-- D1 schema: SQLite dialect, tenant_id first
CREATE TABLE projects (
  id           TEXT PRIMARY KEY,
  tenant_id    TEXT NOT NULL,
  name         TEXT NOT NULL,
  created_at   INTEGER NOT NULL DEFAULT (unixepoch())
);

CREATE INDEX idx_projects_tenant_created
  ON projects(tenant_id, created_at DESC);

Stärken: Wo D1 gewinnt

D1s drei Produktionsvorteile haben sich über alle acht Deployments gehalten.

Erstens regionale Read Replicas ohne Connection Pool. D1 erstellt automatisch Read Replicas über das Cloudflare-Netzwerk, und ein Primary-Key-Read vom nächstgelegenen Replica kehrt in meinen Traces in unter 1,5 ms zurück. Laut D1-Dokumentation ist das Binding aus Sicht des Requests zustandslos — kein Pool zu tunen, kein Max-Connections-Limit zu treffen. Für einen Solo-Entwickler ist diese operationale Einfachheit echtes Geld wert.

Zweitens SQLite Query Planner. SQLite ist eine Single-File-Engine mit konservativem Planner. Laut SQLite-Query-Planner-Dokumentation ist der Planner versionsübergreifend konsistent — das EXPLAIN-Output in der Entwicklung ist der Plan in der Produktion. Diese Determinismus ist mehr wert als ein schlauerer Planner.

Drittens Workers-native Integration. D1 ist ein Binding in env, kein Connection String. Kein Treiber, kein pg-Client, kein SSL-Handshake — das Binding ist einfach da, wenn der Worker startet. Für eine Cloudflare-native SaaS sind die Integrationskosten null.

Grenzen: Wo D1 aufhört, die richtige Wahl zu sein

Drei Grenzen haben mich echte Produktionszeit gekostet.

Erstens der Write Lock auf Datenbankebene. Jede Mutation serialisiert hinter einem einzelnen Write Lock. Das Limit variiert, aber die Form ist konsistent: ein abrupter Abfall nach einigen Hundert Mutationen pro Sekunde auf derselben Datenbank. Der D1-Write-Lock-Postmortem dokumentiert die 250-req/s-Grenze.

Zweitens das 10-GB-Limit pro Datenbank. Laut D1-Limits-Dokumentation ist jede Datenbank auf 10 GB gedeckelt. Bei Multi-Tenant-SaaS-Apps, wo ein Tenant dominiert, ist das eine echte Einschränkung. Die Lösung ist Sharding, aber die operationale Oberfläche wächst.

Drittens die SQLite-spezifische Feature-Lücke. Alles Postgres-spezifische — JSONB-Operatoren, LISTEN/NOTIFY, Advisory Locks — muss in SQLite-Dialekt neu ausgedrückt oder weggelassen werden. Full-Text Search ist das eine Postgres-Feature, das Leute zu verlieren erwarten, das D1 tatsächlich abdeckt: SQLite FTS5 funktioniert im Produktionsbetrieb gut, siehe den D1-FTS5-Full-Text-Search-Guide. Der Optimierungs-Walkthrough steht im D1-Optimization-Writeup.

Postgres-basierte Alternativen für die Produktion

Neon: Serverless Postgres

Neon ist der geistig nächste Verwandte von D1 für einen SaaS-Gründer, aber auf Postgres statt SQLite gebaut. Laut Neon-Dokumentation trennt Neon Compute und Storage: Eine Postgres-kompatible Compute-Schicht liest von einem verteilten Storage-Layer, und kalter Compute startet in ~500 ms. Meine beiden Neon-Deployments sind ein B2B-Analytics-Tool mit ~50k Requests/Tag und ein Developer-Dashboard.

sql

-- Neon / Postgres: same shape, different dialect
CREATE TABLE projects (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id    UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  name         TEXT NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_tenant_created
  ON projects(tenant_id, created_at DESC);

-- Postgres-specific: JSONB indexing for tenant settings
ALTER TABLE tenants ADD COLUMN settings JSONB NOT NULL DEFAULT '{}';
CREATE INDEX idx_tenants_settings ON tenants USING GIN (settings);

Die JSONB-Spalte mit GIN-Index ist genau die Art von Feature, die Neon ab Werk liefert und die SQLite schlicht nicht hat.

Wo Neon gegen D1 gewinnt. Wenn Ihre SaaS von Postgres-spezifischen Features abhängt — JSONB-Indexierung, LISTEN/NOTIFY, pgvector — ist Neon die richtige Wahl. Der Postgres-Dialekt ist die Lingua franca von SaaS-Backends, und fast jede SaaS-Library setzt ihn voraus. Für eine SaaS, die Ingenieure einstellt, ist „Postgres" eine Recruiting-Story; „SQLite am Edge" braucht Erklärung.

Wo Neon gegen D1 verliert. Die Cold-Start-Latenz von einem Cloudflare Worker zu Neon liegt in meinen Messungen bei ~50 ms RTT — eine 30-fache Verschlechterung gegenüber D1s Sub-Millisekunden-Replica-Reads. Bei einem Request-Pfad mit 5–10 Datenbankaufrufen summiert sich das. Neon hat wie jeder Postgres Connections, und das richtige Pattern aus Workers ist Hyperdrive als Connection Pooler.

Supabase: Postgres + Auth + Storage im Bundle

Supabase ist eine andere Form von Alternative: nicht nur eine Datenbank, sondern ein meinungsstarkes Backend-as-a-Service. Laut Supabase-Dokumentation liefert es Postgres für Daten, GoTrue für Auth, Storage für Dateien und Edge Functions für Compute — hinter einem einzigen Dashboard und SDK. Für einen Solo-Gründer ist der Reiz real: ein Vendor für die langweilige Hälfte des Stacks.

Wo Supabase gewinnt. Das Auth- und Storage-Bundle ist der Differenzierer. Gehostete Auth mit E-Mail/Passwort, OAuth, Magic Links und Row-Level-Security-Policies — Supabase shippt es. File Storage mit Image-Transforms — Supabase shippt es. Ein Dashboard für Nutzer, Tabellen und Storage — Supabase shippt es. Für ein MVP ist das der schnellste Weg.

Wo Supabase gegen D1 verliert. Das Bundle ist auch Lock-in: Auth-Flows, RLS-Policies und Storage-URLs sind alle Supabase-förmig; die Migration weg ist echte Arbeit. Die Cold-Start-Latenz von einem Cloudflare Worker liegt bei ~50 ms RTT, weil auch Supabase Postgres betreibt. Bei einer App mit 10+ Datenbankaufrufen pro Request summiert sich das.

SQLite am Edge: Turso und libSQL

Turso: libSQLs Multi-Region-Edge

Turso ist der direkteste Wettbewerber zu D1 in der Kategorie SQLite-am-Edge. Laut Turso/libSQL-Dokumentation betreibt Turso libSQL — einen SQLite-Fork mit Netzwerkreplikation, Embedded Replicas und einer Multi-Region-Topologie, die Sie steuern. Meine beiden Turso-Projekte sind kleinere SaaS-Apps, bei denen ich explizite Replica-Platzierung pro Region wollte.

typescript

// Turso: libSQL embedded replica at the edge
import { createClient } from '@libsql/client'

const db = createClient({
  url: 'file:./local-replica.db',
  syncUrl: 'libsql://my-db.turso.io',
  authToken: process.env.TURSO_TOKEN,
})

// Reads served from the local embedded replica; syncs from primary
const projects = await db.execute('SELECT * FROM projects WHERE tenant_id = ?', [tenantId])

Das Embedded-Replica-Pattern ist libSQLs distintiver Vorteil — eine SQLite-Datei an den Edge ausliefern, vom Primary syncen lassen, und Reads sind lokal ohne Netzwerk-Roundtrip.

Wo Turso gegen D1 gewinnt. Die Replica-Topologie gehört Ihnen. Wenn Ihre Nutzerbasis in drei konkreten Regionen konzentriert ist und Sie garantierte Replica-Platzierung dort wollen, lässt Turso Sie das festnageln. libSQL unterstützt auch Embedded Replicas — eine SQLite-Datei am Edge, die vom Primary synct. Bei starker regionaler Konzentration ein echter Vorteil.

Wo D1 gegen Turso gewinnt. D1s Integration mit Cloudflare Workers ist enger. Kein Treiber, keine zweite Vendor-Beziehung, keine zweite Abrechnungszeile. D1-Replicas sind automatisch; Turso verlangt, dass Sie sie platzieren. D1 ist bei moderater Skalierung auch deutlich günstiger — das Free Tier deckt eine echte SaaS-MVP ab.

NoSQL- und Key-Value-Alternativen

Cloudflare Durable Objects

Durable Objects sind keine Datenbank in derselben Form wie D1, aber für das richtige SaaS-Pattern sind sie das richtige Primitiv. Laut Cloudflare-Durable-Objects-Dokumentation ist jedes Durable Object eine Single-Threaded-Compute-Instanz mit einem Strongly-Consistent-Key-Value-Store, per ID adressierbar und garantiert jeweils in einer Region laufend.

Wo Durable Objects gewinnen. Echtzeit-Koordination — ein Chatraum, ein Multiplayer-Spiel — ist der Lehrbuch-Fall. Die Single-Threaded-Garantie bedeutet keinen Write Lock: Nur ein Request läuft jeweils gegen das Objekt, und es ist Ihr eigener Code. Für Per-Entity-State — eine Buchung, eine Websocket — sind Durable Objects das richtige Primitiv.

Wo D1 gegen Durable Objects gewinnt. „Gib mir alle Projekte dieses Tenants" — eine Multi-Row-Query über viele Tenants — ist D1s Terrain. Durable Objects sind nicht für Cross-Object-Queries gebaut; Sie bräuchten ein D1 daneben. Die richtige Architektur: ein Durable Object pro aktiver Session plus eine D1-Datenbank für Cross-Entity-Queries.

Cloudflare KV

Cloudflare KV ist die einfachste der Alternativen: ein globaler Key-Value-Store mit Eventual Consistency und einem 25-MB-Limit pro Wert. Das richtige Primitiv für Feature Flags, Session-Blobs und Konfiguration — und das falsche für jede relationale Workload.

Die Entscheidungsmatrix: Welche Datenbank wann

Die Wahl ist nicht, welche Datenbank „am besten" ist — sondern welcher Trade-off zur Form Ihrer App passt. Unten die Matrix, die ich Gründern bei Beratungen gebe, und die Matrix hinter der Datenbankwahl in TanStack Ship.

SaaS-Form	Primäre Datenbank	Warum
Workers-native SaaS, leseLastig, regionale Konzentration	D1	Sub-ms-Reads regional, kein Connection Pool
Postgres-spezifische Features (`JSONB`, `LISTEN/NOTIFY`, `pgvector`)	Neon	Postgres-Dialekt, serverless Skalierung
MVP mit Auth + Storage + Datenbank bei einem Vendor	Supabase	Gebündeltes BaaS, schnellster Weg zum Produkt
Multi-Region mit eigener Replica-Platzierung	Turso	libSQL Embedded Replicas, Sie kontrollieren die Topologie
Echtzeit-Per-Entity-State (Chat, Sessions, Multiplayer)	Durable Objects	Single-Threaded-Garantie, kein Write Lock
Feature Flags, Session-Blobs, Config	KV	Eventual Consistency genügt
Write-lastiges Billing, Audit Logs	D1 + Cloudflare Queue	D1 für den User Path, Queue für Write-Fan-out
Multi-Tenant-SaaS mit >10-GB-Tenants	Geshardetes D1 oder Neon	D1-Limit erzwingt Sharding

Für die meisten SaaS-Apps, die ich 2026 ausgeliefert habe — leseLastige Dashboards, Projektlisten, Settings, Billing-Zusammenfassungen, CRUD — war D1 der richtige Default. Das Pattern: D1 für Anwendungsdaten, Durable Objects für Per-Entity-Echtzeit-State, Cloudflare Queues für Write-Pfade mit wenigen Sekunden Latenztoleranz, KV für Feature Flags und Config. Dieser Stack ist jetzt der Default in TanStack Ship, mit Patterns dokumentiert im D1 Production Guide und im D1-Deep-Dive-Writeup.

Die ehrliche Zusammenfassung

Die Marketingseite jeder Datenbank hat auf ihrer eigenen Achse recht: D1 ist schnell am Edge, Neon hat Postgres, Supabase hat das Bundle, Turso hat die Topologie, Durable Objects haben die Garantie. Die Entscheidung ist, auf welcher Achse Ihre SaaS lebt. Für eine Workers-native, leseLastige SaaS 2026 ist D1 der richtige Default.

Wenn Sie Datenbanken für Ihre SaaS evaluieren, sehen Sie sich die TanStack-Ship-Features-Seite, den D1-Performance-Benchmark-Post, den D1 Production Guide und den D1-Deep-Dive-Writeup an. Für den Vorfall, der mir die Write-Lock-Grenze gelehrt hat: D1-Write-Lock-Postmortem. Für den breiteren SaaS-Architektur-Kontext: SaaS Architecture Guide.

Cloudflare D1 vs Supabase vs Postgres: Benchmarks 2026