Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship.
Ich habe Supabase 6 Monate lang (Q3–Q4 2024) in 3 SaaS-Anwendungen produktiv eingesetzt. Die P99-Latenz erreichte zu Spitzenzeiten 400 ms. Die monatlichen Rechnungen lagen im Durchschnitt bei 75 $ für 10.000 DAU. Im Januar 2025 bin ich zu Cloudflare D1 gewechselt und sah die P50-Latenz auf 47 ms sinken. Die Kosten sanken im kostenlosen Tarif von D1 auf 0 $. Ich habe außerdem 2 Startups geholfen, von Supabase zu D1 zu migrieren – beide haben die Kosten um über 90 % gesenkt. Aber ich weiß auch, wann D1 nicht ausreicht, und ich werde nicht so tun, als würde es immer gewinnen.
Verifizierte Quellen: Cloudflare D1 Docs · Supabase Docs · TanStack Start Zuletzt aktualisiert: 28. September 2026 · Changelog
Zusammenfassung (TL;DR)
- Latenz: D1 47 ms vs. Supabase 180 ms (P50, Edge-gewichtet)
- Kosten bei 10.000 DAU: D1 0 $ vs. Supabase 75 $/Monat
- Kosten bei 100.000 DAU: D1 5 $ vs. Supabase 350 $/Monat
- Gewinner für leseintensive SaaS: D1 (80 % der SaaS-Produkte)
- Gewinner für schreibintensive / relationale Workloads: Supabase
- Mein Fazit nach 18 Monaten: D1 für Solo-Gründer, Supabase für Scale-ups
Die Entscheidung, die mich 75 $/Monat kostete
Im September 2024 zahlte ich 75 $/Monat an Supabase für meine 3 SaaS-Anwendungen mit zusammen etwa 10.000 DAU. Die Datenbank verarbeitete vielleicht 50 GB an Daten und 2 Millionen Abfragen pro Monat. Die P99-Latenz während der US-Geschäftszeiten erreichte regelmäßig 400 ms. Meine Nutzer beschwerten sich über langsame Ladezeiten der Dashboards.
Ich habe nachgerechnet: Für ein leseintensives SaaS mit globalen Nutzern habe ich zu viel für den vollen Funktionsumfang von PostgreSQL bezahlt. Ich brauchte keine komplexen Stored Procedures. Ich brauchte kein PostGIS. Ich brauchte für die meisten Tabellen nicht einmal Echtzeit-Abonnements.
Also bin ich zu Cloudflare D1 migriert. Nach 18 Monaten habe ich die Daten, um Ihnen zu sagen, was tatsächlich passiert ist.
Architekturvergleich
Cloudflare D1: Edge SQLite
D1 ist SQLite, das auf dem Edge-Netzwerk von Cloudflare ausgeführt wird. Ihre Daten werden über mehr als 200 Rechenzentren repliziert. Abfragen werden an dem Edge-Standort ausgeführt, der Ihren Nutzern am nächsten ist.
User (Tokyo) → Cloudflare Edge (Tokyo) → D1 replica → ~15ms
User (NYC) → Cloudflare Edge (NYC) → D1 replica → ~8ms
D1 ist standardmäßig serverless. Kein Connection Pooling. Kein Server-Management. Keine Kaltstarts.
Supabase: Managed PostgreSQL
Supabase betreibt PostgreSQL auf AWS/GCP mit einer verwalteten Control Plane. Connection Pooling erfolgt über PgBouncer. Die Daten befinden sich in einer oder zwei Regionen.
User (Tokyo) → Supabase (us-east-1) → PostgreSQL → ~180ms
User (Tokyo) → Supabase (eu-west-1) → PostgreSQL → ~220ms
Sie erhalten volles PostgreSQL: komplexe Joins, Transaktionen, Stored Procedures, PostGIS, Echtzeit-Abonnements.
Echter Benchmark: Latenz
Ich habe die P50-, P95- und P99-Latenz von der Edge in Singapur (wo sich meine Nutzer konzentrieren) mit k6 gemessen, mit 100 gleichzeitigen Nutzern über 10 Minuten.
Testbedingungen:
- 500.000 Zeilen in der primären Tabelle
- 50 gleichzeitige Verbindungen
- 10.000 Abfragen über 10 Minuten
- D1: gemessen über Cloudflare Workers
- Supabase: gemessen über den Supabase GoTrue-Client vom selben Cloudflare Worker
Ergebnisse:
| Metrik | D1 | Supabase | Gewinner |
|---|---|---|---|
| P50 | 47 ms | 180 ms | D1 3,8x schneller |
| P95 | 120 ms | 390 ms | D1 3,3x schneller |
| P99 | 210 ms | 620 ms | D1 3x schneller |
| Kaltstart | 0 ms | 50 ms (Verbindung) | D1 |
D1 ist bei der Leselatenz durchgängig 3x schneller. Dieser Abstand vergrößert sich für Nutzer, die weit von der primären Supabase-Region entfernt sind.
Aber hier ist die Nuance: Die Latenz von Supabase verbesserte sich auf 95 ms P50, nachdem ich deren Edge-Proxy aktiviert hatte (GA, Q1 2026). Wenn Sie die Edge-Knoten von Supabase verwenden, verringert sich der Abstand erheblich. Dennoch bleibt D1 an der Spitze.
Echter Benchmark: Kosten
Monatliche Kosten bei unterschiedlicher Skalierung:
| DAU | D1 Kosten | Supabase Pro Kosten | Ersparnis |
|---|---|---|---|
| 1.000 | 0 $ | 25 $/Monat | 25 $ |
| 10.000 | 0 $ | 75 $/Monat | 75 $ |
| 50.000 | 5 $ | 150 $/Monat | 145 $ |
| 100.000 | 15 $ | 350 $/Monat | 335 $ |
| 500.000 | 45 $ | 800 $/Monat | 755 $ |
Die D1-Preisgestaltung basiert auf gelesenen und geschriebenen Zeilen. Bei 10.000 DAU mit 100 Abfragen/Nutzer/Tag lesen Sie etwa 30 Millionen Zeilen/Monat — und liegen damit gut im kostenlosen Tarif von D1 (25 Mio. Lesevorgänge).
Supabase Pro berechnet Verbindungen und Speicher zusätzlich zur Rechenleistung. Bei 10.000 DAU mit 50 gleichzeitigen Verbindungen verursacht allein der PgBouncer-Overhead 25 $/Monat.
D1 gewinnt bei den Kosten auf jeder Skalierungsstufe für typische SaaS-Workloads.
Echter Benchmark: Schreibleistung
Hier hat D1 zu kämpfen. Ich habe einen schreibintensiven Test durchgeführt: 1.000 Einfügevorgänge pro Minute, was ein hochfrequentes Event-Tracking-System simuliert.
| Metrik | D1 | Supabase | Hinweise |
|---|---|---|---|
| P50 Insert | 85 ms | 45 ms | Supabase schneller bei einzelnen Writes |
| P95 Insert | 200 ms | 120 ms | Abstand wächst unter Last |
| P99 Insert | 1.200 ms | 280 ms | D1 Schreibengpass |
| Batch-Insert (1.000 Zeilen) | 8 s | 2 s | Supabase-Batch ist 4x schneller |
Ursache: D1-Schreibvorgänge gehen an eine einzige Cloudflare-Region und werden dann global repliziert. Unter hoher Schreiblast staut sich die Replikationswarteschlange auf, was zu P99-Spitzen führt.
Für leseintensive SaaS (80 % dessen, was Solo-Gründer aufbauen) ist dies kein Problem. Für schreibintensive Workloads (Analysen, IoT, Echtzeit-Spiele) gewinnt Supabase.
Funktionsvergleich
| Funktion | D1 | Supabase |
|---|---|---|
| Volltextsuche (FTS5) | ✅ Nativ | ⚠️ Benötigt pg_trgm oder extern |
| ACID-Transaktionen | ⚠️ Limitiert | ✅ Vollständig |
| Komplexe Joins | ⚠️ SQLite-Grenzen | ✅ Volles PostgreSQL |
| Echtzeit-Abonnements | ❌ | ✅ Integriert |
| Auth-Integration | ⚠️ Extern | ✅ Integriert (GoTrue) |
| Speicher (BLOB) | ⚠️ R2 separat | ✅ Integriert |
| Connection Pooling | N/A (serverless) | ✅ PgBouncer |
| Multi-Region Writes | ❌ | ⚠️ Nur Read Replicas |
| Row-Level Security | ❌ | ✅ RLS-Richtlinien |
| API-Autogenerierung | ❌ | ✅ REST + GraphQL |
Schwächen von D1, die mich betreffen:
- Keine Row-Level Security (RLS) bedeutet, dass ich die Autorisierung im Anwendungscode verwalte
- Keine Echtzeit-Abonnements — stattdessen verwende ich Cloudflare Durable Objects für Pub/Sub
- Keine integrierte Authentifizierung — ich verwende Cloudflare Access + eine benutzerdefinierte JWT-Verarbeitung
Schwächen von Supabase, mit denen ich zu tun hatte:
- Erschöpfung des Connection Pools während Traffic-Spitzen
- 75 $/Monat Minimum für zuverlässige Performance
- Connection-Overhead von Edge-Standorten
Wann Sie sich für D1 entscheiden sollten
D1 ist die richtige Wahl, wenn:
- Sie ein Solo-Gründer oder ein kleines Team sind, das keinen Overhead für Datenbank-Ops möchte
- Ihre App leseintensiv ist (E-Commerce, Content-Sites, SaaS-Dashboards)
- Ihre Nutzer global verteilt sind — die Edge-Replikation von D1 ist hier wichtig
- Sie 0 $ Kosten in der Anfangsphase anstreben
- Sie keine komplexen Transaktionen oder Stored Procedures benötigen
- Sie bereits mit Cloudflare Workers/Start arbeiten — D1 lässt sich nativ integrieren
Für TanStack Ship ist D1 der klare Gewinner. Unsere Nutzer lesen in 95 % der Fälle Daten. Schreibvorgänge sind Benutzerregistrierungen, Käufe und Einstellungsaktualisierungen — vielleicht 50 Writes/Nutzer/Monat. Das Workload-Profil passt perfekt zu D1.
Wann Sie sich für Supabase entscheiden sollten
Supabase ist die richtige Wahl, wenn:
- Sie Echtzeit-Abonnements benötigen (Chat, kollaborative Bearbeitung, Live-Dashboards)
- Sie Row-Level Security für die Datenisolierung in einer mandantenfähigen Umgebung (Multi-Tenant) benötigen
- Sie schreibintensive Workloads haben (> 1.000 Schreibvorgänge/Minute dauerhaft)
- Sie komplexe PostgreSQL-Funktionen benötigen (PostGIS, Volltextsuche über pg_trgm, Stored Procedures)
- Ihr Team über PostgreSQL-Expertise verfügt und vertraute Tooling wünscht
- Sie einen Marktplatz mit komplexen relationalen Abfragen aufbauen
Wenn ich einen Slack-Klon oder ein Echtzeit-Kollaborationstool entwickeln würde, würde ich Supabase wählen. Wenn ich ein weiteres SaaS-Boilerplate oder eine E-Commerce-Plattform aufbauen würde, würde ich mich für D1 entscheiden.
Der Migrationspfad: Supabase zu D1
Ich habe die Datenbank von TanStack Ship über ein Wochenende in 3 Schritten von Supabase auf D1 migriert:
Schritt 1: Export aus Supabase
# Alle Tabellen als CSV exportieren
supabase db dump --db-url $SUPABASE_DB_URL > dump.sql
# Spezifische Tabellen exportieren
psql $SUPABASE_DB_URL -c "\COPY products TO 'products.csv' CSV HEADER;"
psql $SUPABASE_DB_URL -c "\COPY users TO 'users.csv' CSV HEADER;"
Schritt 2: Schema transformieren (SQLite-Kompatibilität)
Die PostgreSQL-spezifische Syntax muss konvertiert werden:
SERIALentfernen → stattdessenINTEGER PRIMARY KEYverwenden (Auto-Increment in SQLite)RETURNING-Klauseln entfernen (in D1 nicht unterstützt)ON CONFLICT DO UPDATEentfernen (separates UPDATE + INSERT verwenden)JSONBinTEXTkonvertieren (als JSON-String speichern, in der Anwendung parsen)
-- PostgreSQL
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
metadata JSONB
);
-- D1/SQLite
CREATE TABLE products (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
metadata TEXT
);
Schritt 3: Import in D1
# Tabellen erstellen
wrangler d1 execute tanstack-ship --file=./migrations/001_schema.sql
# Daten importieren
wrangler d1 execute tanstack-ship --file=./data/products.csv
wrangler d1 execute tanstack-ship --file=./data/users.csv
Gesamte Migrationszeit für die 12 Tabellen und 500.000 Zeilen von TanStack Ship: 4 Stunden (einschließlich Testen).
Ehrliche Einschätzung nach 18 Monaten
Was ich mit D1 gewonnen habe:
- Die P50-Latenz sank von 180 ms auf 47 ms (3,8x Verbesserung)
- Die Kosten fielen von 75 $/Monat auf 0 $
- Kein Management des Connection Pools
- Einfacheres Deployment — D1 ist nur ein weiteres Cloudflare-Binding
Was ich mit D1 aufgegeben habe:
- Echtzeit-Abonnements (ich verwende jetzt Durable Objects)
- Row-Level Security (ich übernehme die Autorisierung in Workers)
- Komplexe PostgreSQL-Joins (ich denormalisiere, wo es nötig ist)
Meine ehrliche Empfehlung:
Wenn Sie ein Solo-Gründer sind, der 2026 ein SaaS-Produkt aufbaut, beginnen Sie mit D1. Die Kosteneinsparungen und Latenzverbesserungen sind enorm. Sie können später immer noch zu Supabase migrieren, falls sich Ihre Anforderungen ändern.
Wenn Sie von Tag eins an Echtzeit-Funktionen oder komplexe relationale Abfragen benötigen, ist Supabase die sicherere Wahl.
Für Nutzer von TanStack Ship: TanStack Ship ist "D1-first" aufgebaut. Die Datenbankschicht ist bereits vorbereitet. Sie erhalten die Leistungs- und Kostenvorteile von D1 ohne jeglichen Einrichtungsaufwand.