Neon vs PlanetScale vs Supabase: Serverless PostgreSQL im Vergleich 2026
Serverless-Datenbanken sind das meistdiskutierte Thema in der Cloud-Entwicklerwelt der letzten Jahre. Die Versprechen klingen verlockend: automatisches Scaling von 0 auf N, kein Ops-Aufwand, pay-per-use. Neon, PlanetScale und Supabase sind drei der führenden Angebote – aber trotz ähnlicher Marketingsprache verfolgen sie grundlegend unterschiedliche Ansätze.
Neon: PostgreSQL mit Branch-Modell
Neon wurde 2021 von Ex-AWS-RDS-Engineers gegründet mit einem klaren Ziel: serverless PostgreSQL, das sich wie git anfühlt. Das zentrale Feature ist das Branch-Modell: jede Datenbank kann wie ein git-Repo geforkt werden. Entwickler können in Sekunden eine exakte Kopie der Produktionsdatenbank (inklusive Schema und Daten) erstellen, Änderungen testen und den Branch danach löschen.
Neon-Architektur: Neon trennt Compute und Storage voneinander. Der PostgreSQL-Compute kann auf 0 skalieren (Suspend nach Inaktivität), während Storage dauerhaft persistiert. Das ermöglicht echtes "Scale to zero" – ideal für Dev/Test-Umgebungen und kleine Projekte mit sporadischem Traffic.
Neon-Stärken:
- Reines PostgreSQL (100% Kompatibilität, keine versteckten Abweichungen)
- Einzigartiges Branch-Modell (Preview-Umgebungen in CI/CD integrierbar)
- Scale to zero (kein Traffic = kein Compute-Kostenpunkt)
- Sehr günstiger Free Tier (0,5 GB Storage, unlimited Branches)
- Serverless Driver für Edge Functions (kein Standard-TCP erforderlich)
- Teilweise Open Source (Neon-Storage-Engine ist open source)
Neon-Schwächen:
- Kein integriertes Backend-as-a-Service (nur Datenbank, kein Auth, kein Storage)
- Kaltstarts können 1–3 Sekunden dauern (nach Suspend)
- Noch junge Plattform im Vergleich zu Supabase und Airflow
PlanetScale: MySQL mit Vitess-Unterbau
PlanetScale ist das kommerzielle Angebot auf Basis von Vitess, dem von YouTube entwickelten Sharding-Layer für MySQL. PlanetScale hat das Branch-Konzept für Datenbanken mitgeprägt, bevor Neon es für PostgreSQL popularisierte.
Das Differenzierungsmerkmal von PlanetScale ist die Non-Blocking-Schema-Änderung: Migrations in PlanetScale (über Deploy Requests) sperren keine Tabellen, da Vitess Online DDL verwendet. Das ist für Teams mit hochfrequenten Schema-Änderungen bei laufendem Traffic ein bedeutendes Feature.
PlanetScale-Stärken:
- Bewährter Vitess-Unterbau (battle-tested bei Pinterest, Slack, GitHub)
- Non-blocking Migrations via Deploy Requests ohne Downtime
- Exzellentes Developer Experience (CLI, Branch-Workflow)
- Horizontales Sharding möglich (wenn Vitess-Level wirklich benötigt wird)
PlanetScale-Schwächen:
- MySQL, nicht PostgreSQL (für PG-native Features wie JSONB, Arrays nicht geeignet)
- Kein Foreign-Key-Enforcement in der Standardkonfiguration (Vitess-Limitation)
- Preismodell 2023 angepasst: Free Tier abgeschafft, teurer geworden
- Kein echtes "Scale to zero" (mindestens 1 Compute-Instanz aktiv)
- Self-Hosting von PlanetScale nicht möglich (Vitess ist Open Source, aber die PlanetScale-UX nicht)
Supabase: Das Open-Source-Firebase
Supabase positioniert sich nicht nur als Datenbank, sondern als vollständiges Backend-as-a-Service. Auf Basis von PostgreSQL bietet Supabase: Authentifizierung, Storage, Edge Functions (Deno), Realtime-Subscriptions und eine automatisch generierte REST-API (PostgREST) sowie eine GraphQL-API.
Supabase-Philosophie: Open Source first. Der gesamte Supabase-Stack (PostgreSQL + GoTrue Auth + PostgREST + Storage + Realtime) ist selbst hostbar. Supabase Cloud ist der managed Service, aber Migrations und Backups laufen gegen das gleiche Open-Source-System.
Supabase-Stärken:
- Vollständiges Backend-as-a-Service (Auth, Storage, Realtime, API in einem Paket)
- PostgreSQL mit allen Extensions (pgvector für AI, PostGIS für Geo-Daten, etc.)
- Vollständig Open Source und selbst hostbar (kein Vendor-Lock-in)
- Aktive Community, exzellente Dokumentation und viele Starter-Templates
- Kostenloser Tier mit 2 Projekten und 500 MB Datenbank
Supabase-Schwächen:
- Kein "Scale to zero" für die Datenbank (Pause-Feature pausiert das Projekt komplett, nicht nur den Compute)
- Eigene Realtime-Architektur (Elixir-basiert) erfordert Betriebsverständnis beim Self-Hosting
- BaaS-Funktionen können zu Vendor-Coupling führen, wenn API direkt im Client genutzt wird
- Für reine Datenbanknutzung (ohne Auth/Storage) leicht "over-engineered"
Direktvergleich
| Merkmal | Neon | PlanetScale | Supabase |
|---|---|---|---|
| Datenbank | PostgreSQL | MySQL (Vitess) | PostgreSQL |
| Scale to zero | ✓ (echter Compute-Suspend) | ✗ | Eingeschränkt (Pause) |
| Branch-Modell | ✓ | ✓ | Eingeschränkt |
| Auth integriert | ✗ | ✗ | ✓ (GoTrue) |
| Storage integriert | ✗ | ✗ | ✓ |
| Realtime | ✗ | ✗ | ✓ |
| REST-API auto-generated | ✗ | ✗ | ✓ (PostgREST) |
| Self-hosting | Teilweise möglich | ✗ | ✓ vollständig |
| Free Tier | ✓ | ✗ | ✓ |
| Open Source | Teilweise | ✗ | ✓ vollständig |
| Non-blocking Migrations | Standard-PG (pg_advisory_lock) | ✓ (Vitess Online DDL) | Standard-PG |
Für wen ist was geeignet?
Neon ist ideal für:
- Teams, die reines PostgreSQL mit branch-basiertem Dev-Workflow suchen
- Projekte mit sporadischem Traffic (Scale-to-zero spart Kosten erheblich)
- CI/CD-Pipelines mit Datenbank-Branches für Preview-Environments
- Edge-Computing-Szenarien (Serverless Driver ohne TCP erforderlich)
- Startups, die PostgreSQL-First sind und keinen BaaS-Overhead wollen
PlanetScale ist ideal für:
- Teams mit MySQL-Expertise und Bedarf an Non-Blocking-Migrations
- Hochfrequente Schema-Änderungen in Production ohne Downtime
- Vitess-Sharding bei sehr hohen Write-Loads (echte PlanetScale-Stärke)
Supabase ist ideal für:
- Startups und Indie-Entwickler, die ein vollständiges Backend suchen
- Rapid Prototyping mit Auth + Datenbank + Storage in einem System
- Teams, die später self-hosten wollen ohne Lock-in (Docker-Compose-Stack verfügbar)
- Next.js, SvelteKit, Flutter Apps, die schnell eine Backend-Lösung brauchen
- Projekte, die pgvector für AI-Features (RAG, Embeddings) nutzen wollen
Self-Hosting-Optionen
Alle drei Dienste laufen als Cloud-SaaS. Wer Self-Hosting bevorzugt:
- Supabase: Vollständig selbst hostbar (offizieller Docker-Compose-Stack und Kubernetes-Chart verfügbar)
- Neon: Neon-Storage-Engine ist open source, Self-Hosting ist möglich aber komplex
- PlanetScale: Vitess ist open source, aber PlanetScale-UX ist nicht selbst hostbar
Für Self-Hosting-Puristen (Homelab, Kubernetes) ist Supabase die einzige der drei, die wirklich praktisch als eigene Instanz betrieben werden kann – vergleichbar mit Pocketbase vs Supabase vs Firebase.
Kosten im Vergleich
Die Preisgestaltung unterscheidet sich erheblich:
- Neon: Free Tier vorhanden (0,5 GB Storage, Scale to zero). Bezahlt wird pro Compute-Stunde und Storage. Für Dev/Test-Projekte oft nahe null.
- PlanetScale: Kein Free Tier mehr seit 2023. Einstiegspreise bei ca. 39 USD/Monat für Production-Workloads.
- Supabase: Free Tier mit 2 Projekten, 500 MB DB, 1 GB Storage. Pro-Plan ab 25 USD/Monat pro Projekt.
Für kostenbewusste Teams oder frühe Startups sind Neon und Supabase klar vorteilhafter.
Fazit
Alle drei Dienste lösen unterschiedliche Probleme und sind deshalb weniger direkte Konkurrenten als das Marketing suggeriert:
- Neon für Teams, die reines serverless PostgreSQL mit git-artigen Branches und echtem Scale-to-zero suchen
- PlanetScale für MySQL-Teams mit starken Schema-Migration-Anforderungen und Vitess-Sharding-Bedarf
- Supabase für Entwickler, die ein vollständiges, open-source-basiertes Backend-as-a-Service suchen
Wer heute ein neues Projekt startet, PostgreSQL bevorzugt und viele fertige Backend-Features braucht, sollte Supabase als erste Wahl prüfen. Wer hingegen nur eine exzellente serverlose Datenbank mit Branch-Workflow sucht, ist mit Neon oft günstiger und flexibler unterwegs.