Vergleichsartikel zu Serverless-Datenbanken 2026 werden meist von Leuten geschrieben, die einen Anbieter genutzt haben und die Marketing-Seiten der anderen vier gelesen haben. Das ist die Version nach dem Betrieb von Produktionsworkloads auf Supabase, Neon und einer Handvoll Client-Projekte über PlanetScale, Turso und Convex in den letzten 18 Monaten. Fünf Anbieter, echte Produktionsdaten, keine Affiliate-Links.
Ich betreibe Supabase als Hauptsystem auf dieser Website, auf HostList (dem Verzeichnis mit 91.000 Seiten), auf dem WordPress Stack Advisor und auf den meisten Client-Projekten im letzten Jahr. Der HIPAA-Cluster auf dieser Website ist großteils mit Supabase gebaut — das $700/Monat-Setup aus Vercel plus Supabase für Healthcare ist die Architektur, auf die ich mich standardmäßig bei jedem Healthcare-Projekt einlasse, das nicht explizit einen anderen Anbieter braucht. Die ehrliche Übersicht unten zeigt, wo Supabase gewinnt, wo die Alternativen es wirklich schlagen, und wo die Wahl enger ist als das Marketing vermuten lässt.the $700/month Vercel-plus-Supabase healthcare setup is the architecture I default to for any healthcare project that does not specifically need a different vendor. The honest take below covers where Supabase wins, where the alternatives genuinely beat it, and where the choice is closer than the marketing implies.
Die fünf Anbieter in 60 Sekunden
- Supabase — Postgres-as-a-Service mit eingebauter Auth, Storage, Realtime, Edge Functions und pgvector. Pro $25/Monat, Team $599/Monat, HIPAA-Zusatz $350/Monat auf Team oder Enterprise. Das am meisten inklusive System der fünf.
- Neon — Postgres-as-a-Service, Branching-first (jeder Preview-Deploy bekommt einen Datenbank-Branch), serverless Compute mit Scale-to-Zero. Großzügiger kostenlos Tier, Launch $19/Monat, Scale $69/Monat.
- PlanetScale — MySQL-as-a-Service, Vitess-basiert für Sharding, Branching-Workflows. Kostenlose Stufe 2024 entfernt. Scaler $39/Monat, Pro $79+/Monat, Scaler Pro für Production in höheren Tiers.
- Turso — verteiltes SQLite (libSQL), Edge-First-Replikation, kostenlose Stufe 9GB und 1Mrd. Row-Reads, Scaler $29/Monat. Das Schnellste am Edge für Read-Heavy-Workloads.
- Convex — TypeScript-First reaktive Datenbank mit eingebauten Funktionen, Echtzeit-Queries, kein SQL. Kostenlos 1GB, Pro $25/Seat, Team und Enterprise Tiers. Die eigenwilligste der fünf.
Wo jeder Provider tatsächlich gewinnt
Supabase: App + Content + Auth in einem Postgres
Supabase ist die richtige Wahl, wenn deine App und dein Content eine Datenbank teilen und du Auth, Storage und Echtzeit haben möchtest, ohne fünf separate Anbieter zu integrieren. Das Postgres darunter ist echtes Postgres — pgvector für KI-Features, vollständiges SQL, RLS für Multi-Tenant-Sicherheit. Das HIPAA-Add-on für $350/Monat im Team-Plan ist der sauberste Healthcare-Weg für ein Postgres-förmiges Produkt. Der Nachteil: Der Pro-Plan ($25/Monat) ist wirklich begrenzt für Production — Team mit $599/Monat ist, wo ernsthafte Workloads leben, und der Preissprung ist erheblich.
- Gewinnt bei: Full-Stack-Apps, Healthcare mit HIPAA, Projekte die pgvector für KI brauchen, Teams die einen Anbieter für DB+Auth+Storage wollen.
- Schwächen bei: schwere Multi-Region-Writes (Read-Replicas helfen, aber Postgres Single-Master ist die Grenze), reine Database-Only-Briefs, wo die gebündelten Features Rauschen sind.
Neon: Postgres-Branching für Preview-Deploys
Neons Killer-Feature ist Branching — jeder Vercel-Preview-Deploy bekommt seinen eigenen ephemeren Postgres-Branch mit allen Daten, keine Fixtures. Für Teams, die mehrere PRs pro Woche mit datenbankberührenden Änderungen liefern, zahlt sich diese eine Funktion für die Migration aus. Die Serverless-Scale-to-Zero ist wirklich nützlich für Staging-Umgebungen und Traffic-arme Apps. Der Nachteil: Neon ist ein Database-only-Service, also bringst du deine eigene Auth, Storage, Echtzeit mit. Richtig, wenn du speziell Postgres ohne das Bundle willst.
- Stärken: Entwicklungs-Workflow mit Branching, reine Postgres-Projekte, Teams die bereits Auth0/Clerk/Cognito für Authentication nutzen.
- Schwächen: Fehlende integrierte Auth/Storage bedeutet Service-Stitching, kein HIPAA auf dem Launch-Tier (nur Scale-and-up).
PlanetScale: MySQL im großen Maßstab mit Branching
PlanetScale war Pionier beim Database Branching, hat aber 2024 ihren kostenlosen Tier entfernt, was die Adoption durch Indie-Entwickler erheblich geschädigt hat. Richtig jetzt für Teams, die bereits MySQL im großen Maßstab nutzen und Branching plus Vitess Sharding ohne eigenen Betrieb wünschen. Starke DX, reife Plattform. Falsch für Projekte, die sonst Postgres wählen würden — von Postgres zu MySQL nur wegen des Branching-Features zu wechseln lohnt sich jetzt selten, wo Neon denselben Workflow auf Postgres anbietet.
- Stärken: Bestehende MySQL-Workloads im großen Maßstab, Teams die Vitess Sharding benötigen.
- Schwächen: Indie/kostenlos-Tier-Entwickler (seit 2024 kein Free Tier), Postgres-interessierte Teams, die mehr von Neon profitieren würden.
Turso: Edge-First SQLite für read-heavy Workloads
Turso (libSQL, der SQLite-Fork) repliziert deine Datenbank global zum Edge und serviert Reads aus der Region, auf die der Nutzer trifft. Für read-heavy Anwendungen — Content-Sites mit datenbankgestützten Inhalten, E-Commerce-Kataloge, Verzeichnisse — ist der Latenz-Gewinn dramatisch. Der 9GB kostenlose Tier und 1 Milliarde Zeilen-Reads ist wirklich großzügig. Der Haken: SQLite hat andere Transaction-Semantik als Postgres, write-heavy Anwendungen sind nicht optimal geeignet, und das Ökosystem von ORMs und Tools ist kleiner als für Postgres oder MySQL.
- Stärken: Edge-verteilte read-heavy Apps, Content-Sites mit datenbankgestützten Inhalten im großen Maßstab, großzügiger kostenloser Tier.
- Schwächen: Write-heavy Workloads, komplexe Multi-Table-Transaktionen, Projekte die bereits in Postgres-Ökosystem-Tools investiert sind.
Convex: TypeScript-first reaktive Datenbank
Convex ist die eigenwilligste der fünf — TypeScript-Schemadefinitionen, Server-Funktionen in TypeScript, Real-Time-Abfragen standardmäßig, kein SQL. Für Teams, die durchgehend in TypeScript bleiben möchten und die Developer Experience höher bewerten als Flexibilität, ist Convex wirklich produktiv. Der Trade-off ist die Abhängigkeit: es gibt keine SQL-Fluchtmöglichkeit, das Datenmodell ist Convex-spezifisch, und eine Migration weg von Convex ist ein vollständiger Neubau statt eines Datenbank-Exports.
- Punktet bei: TypeScript-first Teams, Real-Time-intensive Apps, Prototypen-zu-Produktion, wo DX-Geschwindigkeit zählt.
- Schwächen: jeder, der SQL-Flexibilität braucht, Projekte mit hohen Anforderungen an Datenportabilität, komplexe analytische Abfragen.
Entscheidungsbaum — auswählen nach dem Brief
Full-Stack-App mit Content + Auth + Real-Time + KI-Features
Supabase. Die gebündelten Features (Auth, Storage, Realtime, pgvector) sparen echten Overhead bei der Vendor-Verwaltung. Das HIPAA-konforme Supabase + Vercel Setup deckt die produktionsreife Version ab, einschließlich der BAA-Compliance.The HIPAA-compliant Supabase + Vercel setup covers the production-grade version including the BAA story.
Postgres-only-Projekt mit ernsthaften Development-Workflow-Anforderungen
Neon. Branching pro Preview-Deploy ist das Killer-Feature. Kombinieren Sie es mit Auth0, Clerk oder Supabase Auth (ja, Sie können Supabase Auth verwenden, ohne ihre Datenbank zu nutzen) für die Auth-Layer.
MySQL-Workload im großen Maßstab mit Sharding-Anforderungen
PlanetScale. Die Vitess-Sharding-plus-Branching-Kombination ist einzigartig. Wenn du von vorne anfängst, evaluiere zuerst Neon; wenn du bereits bei MySQL in großem Maßstab unterwegs bist und die Plattform ohne eigenes Betreiben möchtest, rechtfertigt PlanetScale den Preis.
Read-heavy edge-distributed content app
Turso. SQLite at the edge mit 1 Milliarde kostenlosen Lesevorgängen ist wirklich eine andere Kategorie. Richtig für Content-Verzeichnisse, E-Commerce-Kataloge, programmatische SEO-Websites, wo Latenz beim Lesen das Nutzererlebnis dominiert.
TypeScript-only team, prototype-shaped product, real-time first
Convex. Die DX-Geschwindigkeit für TypeScript-Teams ist real. Akzeptiere den Lock-in-Kompromiss; überprüfe es neu, wenn das Produkt in etwas skaliert, das SQL oder Datenportabilität erfordert.
Cost economics — annual TCO für eine typische Workload
Verankert an einer hypothetischen SaaS-App: 10.000 aktive Nutzer, 5 GB Datenbank, 100.000 API-Anfragen pro Tag, 5-köpfiges Engineering-Team, wöchentliche Deployments.
- Supabase Team: $599/Monat Basis. Plus HIPAA-Add-on $350/Monat falls erforderlich. ~$11.400/Jahr (oder $7.200 ohne HIPAA).
- Neon Scale: $69/Monat + nutzungsabhängige Compute- und Speicherkosten, typischerweise $40–100/Monat zusätzlich. ~$1.500–2.500/Jahr.
- PlanetScale Scaler Pro: $79/Monat + Nutzungskosten. ~$1.500–2.500/Jahr für ähnliche Workload.
- Turso Scaler: 29 $/Monat plus Nutzung. ~500–800 $/Jahr.
- Convex Pro: 25 $/Seat × 5 + Nutzung = ~2.000–4.000 $/Jahr.
Supabase sieht auf dem Papier in diesem Maßstab teuer aus, aber der Vergleich ist unfair — Neon, PlanetScale, Turso und Convex sind reine Datenbankdienste. Wenn man gleichwertige Auth (Clerk Pro 25 $/Monat + 0,02 $/MAU), Storage (Cloudflare R2 ~15 $/Monat), Real-time (Pusher 49 $/Monat oder selbst gehostet) und pgvector (verwaltet über OpenAI Embeddings + eine Vector DB) hinzufügt, landet man typischerweise bei zusätzlichen 200–500 $/Monat. Sobald man die Integrationen zusammenfasst, wird Supabase Team oft kostenkonkurrenzfähig.
FAQ
Ist Supabase besser als Neon?
Für Full-Stack-Apps mit Auth-, Storage- und Real-time-Anforderungen ja — Supabase bündelt Features, die Neon nicht hat. Für reine Postgres-Projekte mit ernsthaften Anforderungen an den Development Workflow ist Neons Branching der Unterscheidungsfaktor. Die beiden sind auf unterschiedliche Anforderungen optimiert; die Wahl handelt sich selten darum, welches absolut „besser" ist.
Warum hat PlanetScale den kostenlosen Tarif entfernt?
Nachhaltigkeit — pro Kunde Postgres oder MySQL kostenlosen Betrieb im großen Maßstab ist genuiner teuer, und PlanetScale entschied sich, den Fokus auf umsatzgenerierende Kunden statt auf die Indie-/Learning-Community zu legen. Die Entscheidung schadete ihrer Developer-Mindshare erheblich; Neon und Turso haben seitdem die meiste Indie-Aufmerksamkeit auf sich gezogen. PlanetScale bleibt für etablierte Teams mit MySQL eine starke Wahl, ist aber nicht mehr der Standard für neue Projekte.
Ist Turso wirklich eine Postgres-Alternative?
Nein, Turso nutzt libSQL (ein SQLite-Fork), das andere Transaktionssemantik hat, keine vollständigen Multi-Table-Relational-Features besitzt und ein kleineres Ökosystem hat. Für Read-Heavy-Workloads am Edge ist es genuiner schneller als Postgres, aber für allgemeine Application Databases bleibt Postgres die flexiblere Wahl.
Kann ich Convex für etwas anderes als TypeScript-Apps verwenden?
Theoretisch ja — Convex hat SDKs für Python und andere Sprachen — aber die Produktivitätsgeschichte ist auf TypeScript-First-Entwicklung ausgerichtet. Teams, die Convex aus Non-TypeScript-Stacks verwenden, neigen dazu, Reibung zu spüren, weil die Architektur nicht dafür ausgelegt ist, sie zu absorbieren. Für Non-TypeScript-Teams ist normalerweise Supabase oder Neon die bessere Wahl.
Welche serverlose Datenbank hat die beste HIPAA-Story?
Supabase, mit dem HIPAA-Add-on für $350/Monat im Team-Plan ($599/Monat). Die kombinierte Plattformebene mit Vercel Pro BAA für $350/Monat bringt dich auf $700/Monat für einen verteidigbaren Next.js + Supabase HIPAA-Stack. Vollständige Einrichtung ist hier dokumentiert. Neon und PlanetScale bieten HIPAA in höheren Stufen an; Turso und Convex haben keine veröffentlichten HIPAA-Stories seit Mitte 2026.Full setup detailed here. Neon and PlanetScale offer HIPAA on higher tiers; Turso and Convex do not have published HIPAA stories as of mid-2026.
Weiterführende Lektüre
HIPAA-compliant Supabase + Vercel: das $700/Monat-Setup — Produktionseinrichtung für Healthcare-Apps mit Supabase als Datenschicht. — production setup for healthcare apps using Supabase as the data layer.
Headless CMS Hub — wenn sich die CMS-Layer-Wahl mit der Datenbankwahl schneidet (Supabase als Content vs. separate CMS). — when the CMS layer choice intersects with the database choice (Supabase as content vs separate CMS).
How I built a 25,000-page directory in Next.js — die Produktionsfallstudie in großem Maßstab, mit Supabase als Datenrückgrat. — the production case study at scale, with Supabase as the data backbone.
WordPress Stack Advisor — das Tool selbst läuft auf Supabase + Vercel; Produktionsreferenz für das Supabase + Next.js-Muster. — the tool itself runs on Supabase + Vercel; production reference for the Supabase + Next.js pattern.
Die Datenbankwahl ist selten der Engpass. Der Engpass ist, ob das Team in der gewählten Datenbank ausliefern kann. Wähle nach Primitive-Passung, nicht nach Feature-Checkliste.
Buchen Sie ein 30-minütiges Datenbankgespräch — beschreiben Sie die App-Struktur, die Stack-Expertise des Teams und die Skalierungsprognose. Verlassen Sie das Gespräch mit einer Supabase-vs-Neon-vs-Turso-Entscheidung, die zu Ihrem Brief passt. — describe the app shape, the team's stack expertise, the scale projection. Walk away with a Supabase-vs-Neon-vs-Turso decision that fits the brief.