serverless-databases-2026-supabase-neon-planetscale-turso-convex.html
< BACK Headerbild für Serverless-Datenbanken 2026: Supabase, Neon, PlanetScale, Turso, Convex — ausgewählt nach Anforderung

Serverlose Datenbanken 2026: Supabase, Neon, PlanetScale, Turso, Convex -- ausgewählt nach praktischem Nutzen

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.Supabase, Neon, and a handful of client builds across PlanetScale, Turso, and Convex over the last 18 months. Five providers, real production data, no 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.Supabase is the bundled default, Neon is the Postgres purist pick, PlanetScale wins MySQL branching, Turso wins edge reads, and Convex wins TypeScript-first reactivity.

Ich betreibe Supabase als primäre Lösung auf dieser Website, auf HostList (das Verzeichnis mit 91.000 Seiten), auf dem WordPress Stack Advisor und bei den meisten Client-Projekten im letzten Jahr. Der HIPAA-Cluster auf dieser Website ist größtenteils Supabase-gebaut -- das $700/Monat-Setup aus Vercel-plus-Supabase für den Healthcare-Bereich ist die Architektur, auf die ich bei jedem Healthcare-Projekt zurückgreife, das keinen anderen Anbieter spezifisch benötigt. Die ehrliche Analyse unten zeigt, wo Supabase überzeugt, wo die Alternativen es wirklich schlagen, und wo die Wahl knapper ist als das Marketing suggeriert.WordPress Stack Advisor, and on most client work in the last year. The HIPAA cluster on this site is largely Supabase-built -- 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 integriertem Auth, Storage, Realtime, Edge Functions und pgvector. Pro $25/Monat, Team $599/Monat, HIPAA-Add-on $350/Monat für Team oder Enterprise. Das vollständigste Paket der fünf.
  • Neon -- Postgres-as-a-service, Branching-first (jeder Preview Deploy bekommt einen Database Branch), serverlose Compute mit Scale-to-zero. Großzügiger Free-Tier, Launch $19/Monat, Scale $69/Monat.
  • PlanetScale -- MySQL-as-a-service, Vitess-basiert für Sharding, Branching-Workflows. Hat den Free-Tier 2024 entfernt. Scaler $39/Monat, Pro $79+/Monat, Scaler Pro für Production bei höheren Tiers.
  • Turso -- verteiltes SQLite (libSQL), Edge-first Replikation, Free-Tier mit 9GB und 1B Row Reads, Scaler $29/Monat. Das schnellste an der Edge für Read-Heavy-Workloads.
  • Convex -- TypeScript-first reaktive Datenbank mit integrierten Funktionen, Real-time Queries, kein SQL. Free 1GB, Pro $25/Seat, Team und Enterprise Tiers. Das Meinungsstärkste 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 gemeinsame Datenbank nutzen und du Auth, Storage und Real-time haben möchtest, ohne fünf separate Anbieter zu integrieren. Das Postgres darunter ist echtes Postgres -- pgvector für AI-Features, vollständiges SQL, RLS für Multi-Tenant-Sicherheit. Das HIPAA-Add-on für $350/Monat im Team-Plan ist der saubere Healthcare-Weg für ein Postgres-basiertes Produkt. Der Nachteil: Der Pro-Plan ($25/Monat) ist für Production wirklich begrenzt -- Team für $599/Monat ist dort, wo ernsthafte Workloads laufen, 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 kurzlebigen Postgres-Branch mit vollem Datensatz, keine Fixtures. Für Teams, die mehrere PRs pro Woche mit datenbankverändernden Änderungen ausliefern, zahlt sich dieses eine Feature für die Migration aus. Die serverlose Scale-to-Zero ist wirklich nützlich für Staging-Umgebungen und Low-Traffic-Apps. Der Nachteil: Neon ist ein reiner Datenbankdienst, also bringst du deine eigene Auth, Storage und Real-Time mit. Die richtige Wahl, wenn du speziell Postgres ohne Bundle willst.Vercel preview deploy gets its own ephemeral Postgres branch with the full data, no fixtures. For teams that ship multiple PRs per week with database-touching changes, this single feature pays for the migration. The serverless scale-to-zero is genuinely useful for staging environments and low-traffic apps. The downside: Neon is a database-only service, so you bring your own auth, storage, real-time. Right call when you specifically want Postgres without the bundle.

  • 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 der Pionier des Database Branching, hat aber 2024 ihren kostenlosen Plan gestrichen, was die Adoption durch Indie-Developer erheblich geschadet hat. Die richtige Wahl jetzt für Teams, die bereits im großen Stil auf MySQL setzen und Branching plus Vitess Sharding ohne Selbstbetrieb wollen. Starke DX, reife Platform. Die falsche Wahl 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, da Neon denselben Workflow auf Postgres liefert.

  • 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 an den Edge und bedient Lesevorgänge von der Region, in die der User geht. Für Read-Heavy-Anwendungen – Content-Sites mit datenbankgestütztem Content, E-Commerce-Kataloge, Verzeichnisse – ist der Latenz-Gewinn dramatisch. Der 9-GB-Free-Tier und 1 Milliarde Row Reads sind echt großzügig. Der Haken: SQLite hat andere Transaction-Semantik als Postgres, Write-Heavy-Anwendungen sind kein optimaler Fit, 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 opinionierte Lösung von den fünf – TypeScript Schema-Definitionen, Server-Funktionen in TypeScript, Real-Time-Queries standardmäßig, kein SQL. Für Teams, die komplett in TypeScript bleiben wollen und Developer Experience über Flexibilität schätzen, ist Convex echt produktiv. Der Trade-off ist Lock-In: es gibt keine SQL-Fluchtluke, das Datenmodell ist Convex-spezifisch, und die Migration weg von Convex ist ein vollständiger Rebuild 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 – wähle 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.

Kostenökonomie – jährliche TCO für einen typischen 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 teuer aus in dieser Größenordnung, aber der Vergleich ist unfair – Neon, PlanetScale, Turso und Convex sind reine Datenbankdienste. Wenn du äquivalente Auth (Clerk Pro $25/Monat + $0,02/MAU), Storage (Cloudflare R2 ~$15/Monat), Real-Time (Pusher $49/Monat oder Self-Host) und pgvector (verwaltet über OpenAI Embeddings + eine Vector DB) addierst, landet man typischerweise bei $200–500/Monat zusätzlich. Wenn du die Integrationen bundlest, 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 bundelt Features, die Neon nicht hat. Für reine-Postgres-Projekte mit ernsthaften Development-Workflow-Anforderungen ist Neons Branching der Differentiator. Die beiden sind für unterschiedliche Briefs optimiert; die Wahl geht selten darum, welche absolut 'besser' ist.

Warum hat PlanetScale den kostenlosen Tarif entfernt?

Nachhaltigkeit – Pro-Kunde Postgres oder MySQL ohne Kosten zu betreiben ist in der Größenordnung echt teuer, und PlanetScale entschied sich, sich auf umsatzgenerierende Kunden statt auf die Indie-/Learning-Community zu konzentrieren. Die Entscheidung schadete ihrem Developer-Mindshare erheblich; Neon und Turso fingen danach die meiste Indie-Aufmerksamkeit ab. 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äts-Story ist um TypeScript-First-Development gebaut. Teams, die Convex von Non-TypeScript-Stacks aus nutzen, erleben typischerweise Reibung, die die Architektur nicht absorbieren soll. Für Non-TypeScript-Teams ist Supabase oder Neon meist der 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.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-konformes Supabase + Vercel: das 700-Dollar-Setup – Produktionssetup für Healthcare-Apps mit Supabase als Datenschicht. -- production setup for healthcare apps using Supabase as the data layer.

Headless CMS Hub – wenn die CMS-Layer-Wahl mit der Datenbankwahl verschmilzt (Supabase als Content vs. separates CMS). -- when the CMS layer choice intersects with the database choice (Supabase as content vs separate 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. -- 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.

Buche einen 30-minütigen Datenbanktermin – beschreibe die App-Form, die Stack-Expertise des Teams, die Skalierungsprognose. Gehe mit einer Supabase-vs-Neon-vs-Turso-Entscheidung, die zum Brief passt, weg. -- 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.

< BACK