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.
Kernaussage: Supabase ist der gebündelte Standard, Neon ist die Wahl für Postgres-Puristen, PlanetScale gewinnt beim MySQL-Branching, Turso gewinnt bei Edge-Lesezugriffen, und Convex gewinnt bei TypeScript-first Reaktivität.
Ich betreibe Supabase als Hauptdatenbank auf dieser Website, auf HostList (das 91.000-Seiten-Verzeichnis), auf dem WordPress Stack Advisor und in den meisten Client-Projekten des letzten Jahres. Der HIPAA-Cluster auf dieser Website ist größtenteils mit Supabase gebaut, das $700/Monat-Setup aus Vercel plus Supabase ist die Architektur, auf die ich mich bei jedem Healthcare-Projekt einlasse, das nicht explizit einen anderen Anbieter benötigt. Die ehrliche Bewertung unten behandelt, wo Supabase gewinnt, wo die Alternativen es wirklich schlagen, und wo die Wahl näher beieinander liegt, als das Marketing suggeriert.
Die fünf Anbieter in 60 Sekunden
- Supabase, Postgres-as-a-Service mit eingebautem Auth, Storage, Realtime, Edge Functions und pgvector. Pro $25/Monat, Team $599/Monat, HIPAA-Add-on $350/Monat auf Team oder Enterprise. Die umfassendste Lösung der fünf.
- Neon, Postgres-as-a-Service, Branching-First (jeder Preview-Deploy bekommt einen Database-Branch), serverlose Compute-Skalierung auf null. Großzügiger kostenloser Plan, Launch $19/Monat, Scale $69/Monat.
- PlanetScale, MySQL-as-a-Service, Vitess-basiert für Sharding, Branching-Workflows. Der kostenlose Plan wurde 2024 eingestellt. Scaler $39/Monat, Pro $79+/Monat, Scaler Pro für Production bei höheren Tiers.
- Turso, verteiltes SQLite (libSQL), Edge-first-Replikation, kostenlos 9GB und 1 Mrd. Row Reads, Scaler $29/Monat. Das schnellste am Edge für Read-Heavy-Workloads.
- Convex, TypeScript-first reaktive Datenbank mit eingebauten Funktionen, Echtzeit-Abfragen, kein SQL. Kostenlos 1GB, Pro $25/Seat, Team- und Enterprise-Tiers. Die gefestiegtste Lösung 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 Inhalte eine Datenbank teilen und du Auth, Storage und Realtime ohne Integration von fünf separaten Anbietern haben möchtest. 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 auf Team ist der saubere Healthcare-Weg für ein Postgres-förmiges Produkt. Der Nachteil ist, dass der Pro-Plan ($25/Monat) für Production wirklich begrenzt ist, Team bei $599/Monat ist das Zuhause für ernsthafte Workloads, und die Preisstufe 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 vollständigen Daten, keine Fixtures. Für Teams, die mehrere PRs pro Woche mit Datenbankänderungen deployen, zahlt sich dieses eine Feature für die Migration aus. Die serverlose Skalierung auf null ist wirklich nützlich für Staging-Umgebungen und Low-Traffic-Apps. Der Nachteil: Neon ist ein reiner Datenbankdienst, du bringst dein eigenes Auth, Storage, Realtime mit. Richtig, wenn du explizit 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 seinen kostenlosen Plan eingestellt, was die Adoption durch Indie-Developer erheblich beeinträchtigt hat. Die richtige Entscheidung jetzt für Teams, die bereits MySQL im großen Maßstab nutzen und Branching plus Vitess Sharding ohne selbst gehostete Lösung wollen. Starke DX, ausgereiftes System. Die falsche Entscheidung 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 noch, da 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 bis ans Edge und bedient Lesezugriffe von der Region, auf die der Benutzer trifft. Für Lese-lastige Anwendungen, inhaltsgetriebene Websites mit datenbankgestütztem Inhalt, E-Commerce-Kataloge, Verzeichnisse ist der Latenzgewinn dramatisch. Der 9-GB-Plan kostenlos und 1 Milliarde Lesezugriffe ist wirklich großzügig. Der Haken: SQLite hat andere Transaction-Semantik als Postgres, Schreib-lastige Anwendungen sind kein optimaler Use-Case, und das Ökosystem von ORMs und Tools ist kleiner als bei 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 eigenständigste der fünf, TypeScript-Schema-Definitionen, Server-Funktionen in TypeScript, Echtzeit-Queries standardmäßig, kein SQL. Für Teams, die vollständig in TypeScript bleiben wollen und Developer Experience über Flexibilität schätzen, ist Convex wirklich produktiv. Der Trade-off ist der Lock-in: Es gibt keine SQL-Fluchtluke, das Datenmodell ist Convex-spezifisch, und ein Umzug von Convex ist ein vollständiger Neuaufbau statt einem Datenbankexport.
- 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, wähle basierend auf der Aufgabenstellung.
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.
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.
Kosteneffektivität, jährliche 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 bei diesem Maßstab teuer aus, aber der Vergleich ist unfair – Neon, PlanetScale, Turso und Convex sind reine Datenbankdienste. Das Hinzufügen von gleichwertiger Auth (Clerk Pro $25/Monat + $0,02/MAU), Storage (Cloudflare R2 ~$15/Monat), Echtzeit (Pusher $49/Monat oder selbst gehostet) und pgvector (verwaltet über OpenAI-Embeddings + eine Vector DB) landet typischerweise bei $200–500/Monat zusätzlich. Wenn du die Integrationen bundeln, wird Supabase Team oft kostenkonkurrenzfähig.
FAQ
Ist Supabase besser als Neon?
Für Full-Stack-Apps mit Auth-, Storage- und Echtzeit-Anforderungen: Ja, Supabase bündelt Features, die Neon nicht hat. Für reine Postgres-Projekte mit ernsthaften Development-Workflow-Anforderungen ist Neons Branching der Differentiator. Die zwei sind für verschiedene Aufgabenstellungen optimiert; die Wahl geht selten darum, welches in absoluten Begriffen „besser" ist.
Warum hat PlanetScale den kostenlosen Tarif entfernt?
Nachhaltigkeit: Pro-Kunde Postgres oder MySQL ohne Kosten zu betreiben ist im großen Maßstab wirklich teuer, und PlanetScale entschied sich, sich auf umsatzgenerierende Kunden statt auf das Indie-/Learning-Publikum zu konzentrieren. Die Entscheidung schadete ihrem Developer-Mindshare deutlich; Neon und Turso fingen seitdem die meiste Indie-Aufmerksamkeit auf. PlanetScale bleibt eine starke Wahl für etablierte Teams auf MySQL, 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 um TypeScript-first-Development gebaut. Teams, die Convex aus Non-TypeScript-Stacks nutzen, erleben tendenziell Reibung – die Architektur ist nicht designed, um das zu absorbieren. Für Non-TypeScript-Teams sind Supabase oder Neon meist das bessere Fit.
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.
Weiterführende Lektüre
HIPAA-kompatible Supabase + Vercel: das $700/Monat-Setup, Produktionssetup für Healthcare-Apps mit Supabase als Datenschicht.
Headless CMS Hub, wenn die CMS-Layer-Wahl mit der Datenbankwahl zusammentrifft (Supabase als Content vs. separates CMS).
Wie ich ein 25.000-Seiten-Verzeichnis in Next.js gebaut habe – die Produktions-Fallstudie im großen Maßstab, mit Supabase als Daten-Backbone.
WordPress Stack Advisor, das Tool selbst läuft auf Supabase + Vercel; Produktionsreferenz für das 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.
Buche einen 30-minütigen Datenbank-Call, beschreibe die App-Form, das Stack-Know-how des Teams, die Skalierungsprognose. Gehe weg mit einer Supabase-vs-Neon-vs-Turso-Entscheidung, die zum Brief passt.