Neon vs Supabase vs PlanetScale: Entscheidungsmatrix für SaaS

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich betreibe sieben SaaS-Apps auf Cloudflare Workers. Vier laufen auf Neon, zwei auf Supabase und eine auf PlanetScale. Vor diesem Vergleich hatte ich zwei weitere auf Supabase und eine auf PlanetScale, die inzwischen migriert wurden. Dieser Beitrag ist der 30-Tage-Test, den ich im März und April 2026 durchgeführt habe, um einen Standard für TanStack Ship zu wählen und ehrlich darüber zu sein, wo jede Datenbank punktet. Kein Anbieter hat diesen Beitrag gesponsert; ich bezahle jede Datenbank aus eigener Tasche. Offenlegung: Dies ist ein unabhängiger Vergleich ohne Affiliate-Links und ohne wesentliche Verbindung zu einem der genannten Anbieter.

Verifizierte Quellen: Neon Pricing · Neon Branching Documentation · Supabase Pricing · Supabase Auth Documentation · PlanetScale Pricing · PlanetScale Boost Documentation · Drizzle ORM Documentation · TanStack Start Server Functions · TanStack Ship GitHub · Postgres Official Documentation Letzte Aktualisierung: 2026-05-11 · Changelog

TL;DR: Für ein Solo-SaaS auf Cloudflare Workers gewinnt Neon bei Cold-Starts, Branching und Kosten für die meisten Workloads. Supabase gewinnt, wenn Sie Auth, Storage und Realtime in einem Panel benötigen und bereit sind, für das Bundle zu zahlen. PlanetScale gewinnt bei reinem Write-Durchsatz und Schemaänderungen ohne Ausfallzeit, aber der Preis in 2026 liegt etwa bei 2x Neon und die MySQL-only-Einschränkung ist real. TanStack Ship setzt standardmäßig auf Cloudflare D1 für Hot Paths und Neon für Cold Paths – diese Kombination deckt 80 % der Solo-SaaS-Workloads ab.

Was ich tatsächlich getestet habe

Bevor ein Vergleich nützlich ist, müssen wir uns als Leser und Autor darüber einig sein, was getestet wird. Das Label „serverless Postgres" wird locker verwendet.

Laut der Neon-Dokumentation ist Neon serverless Postgres mit getrenntem Storage und Compute; Compute kann auf null skaliert werden. Laut der Supabase-Dokumentation ist Supabase gehostetes Postgres mit gebündeltem Auth, Storage, Realtime und Edge Functions. Laut der PlanetScale-Dokumentation ist PlanetScale eine MySQL-kompatible Datenbank, die auf Vitess aufbaut, mit Branching und Schemaänderungen ohne Ausfallzeit; sie tritt in denselben Käufersegmenten auf, ist aber kein Postgres.

Ein Vergleich, der die MySQL/Postgres-Trennung ignoriert, ist irreführend; die Trennung ist entscheidend für ORM-Auswahl, Feature-Parität und Migrationskosten.

Das Testsetup

Ich habe denselben 30-Tage-Benchmark mit identischen Workloads durchgeführt: 12-Tabellen-Schema, 70/25/5 Read/Write/Analytics-Verteilung, us-east-1-Datenbankregion, Cloudflare Workers Edge für die App, Drizzle ORM (Postgres-Dialekt für Neon und Supabase, MySQL für PlanetScale), Test-Query SELECT id, email, created_at FROM users WHERE id = $1.

Die Zahlen stammen aus dem Testlauf, nicht von Anbieter-Benchmarks. PlanetScale und Neon schnitten besser ab als ihre Marketing-Benchmarks vermuten lassen; Supabase war bei Cold-Starts leicht schlechter als vom Marketing impliziert.

Als Hintergrundinformationen empfehle ich Cloudflare D1 vs Postgres in Production und Cloudflare D1 vs Supabase for a Solo Founder SaaS.

Cold-Starts: Die Metrik, die für Edge-Apps am meisten zählt

Für eine Cloudflare-Workers-App ist der Datenbank-Cold-Start der größte PerformancenHebel. Eine Anfrage, die 5 ms am Edge benötigt, aber 800 ms auf eine kalte Datenbank wartet, ist eine 800-ms-Anfrage.

Neons 480ms p99 ist eine Datenbank, die auf null skaliert wurde und bei Bedarf aufwacht. Supabase Free-Tier 1.200ms p99 ist der Fehlerfall, den ich in der Produktion erlebt habe; die erste Anfrage nach 5 Minuten Inaktivität zahlt den vollen Preis. Supabase Pro 90ms p99 ist dieselbe Datenbank mit Always-On-Compute; Sie zahlen mehr, um den Cold-Start zu vermeiden.

Neon ist die einzige der drei Datenbanken, die das Cold-Start-Story standardmäßig richtig umsetzt. Supabase kann nur auf der kostenpflichtigen Stufe mithalten; PlanetScale ist wettbewerbsfähig, aber nicht besser.

Was das für Ihre App bedeutet

Wenn Ihr SaaS konstanten Traffic hat (ein B2B-Dashboard, ein internes Tool), löst der Cold-Start selten aus. Wenn Ihr SaaS bursty Traffic hat (ein Consumer-Tool, das zweimal täglich genutzt wird, ein Webhook-Empfänger), löst der Cold-Start ständig aus und die Datenbankwahl ist der Unterschied zwischen einer 100ms- und einer 1.200ms-Anfrage. Das habe ich bei InvoiceFlow gelernt; Cold-Starts waren kein Problem, bis wir einen Webhook-Empfänger veröffentlicht haben.

Branching: Das Workflow-Feature, das meine Meinung geändert hat

Für Solo-Entwickler ist Database-Branching der größte Produktivitätsgewinn der letzten fünf Jahre. Jeder Git-Branch erhält seine eigene ephemere Datenbank.

Laut der Neon-Branching-Dokumentation bietet Neon Branching als erstklassiges Feature. Jeder Branch ist ein Copy-on-Write-Klon des Parents, kostet etwa $0,10/Tag und kann mit einem API-Call zurückgesetzt werden. Die GitHub-Actions-Integration ist eine Konfigurationsdatei. Mein Sieben-App-Test wäre ohne Branching drei Wochen gedauert und mit Branching drei Tage.

Supabase hat Branching 2025 über die Supabase CLI hinzugefügt. Der Workflow ist schwerfälliger als bei Neon – 30-Sekunden-Projekt-Start und ein von Supabase verwalteter Runner für die GitHub-Integration.

PlanetScale hat Database-Branching für MySQL erfunden. Laut der PlanetScale-Dokumentation ist jeder Branch ein echtes Vitess-Shard mit Schemaänderungen ohne Ausfallzeit. Die Einschränkung ist, dass Sie PlanetScales Deploy Requests verwenden müssen, um Schemaänderungen zusammenzuführen – das ist ein Workflow-Lock-in.

Für Solo-SaaS-Entwickler, die Branches in 30 Sekunden zu cent-Kosten pro Branch wollen, gewinnt Neon. Für Teams mit einem DBA, der Deploy-Request-Reviews möchte, ist PlanetScale der Goldstandard. Supabase ist in Ordnung, aber nicht differenzierend.

Preise bei 10 GB Storage, 50 GB Egress, 100M Row Reads

Hier sind die Mai-2026-Preise für jede Datenbank bei einem Workload, den ich als „real für ein einjähriges SaaS" bezeichnen würde: 10 GB Storage, 50 GB Egress, 100M Reads, 5M Writes pro Monat.

Neon Launch für $19/Monat ist das Günstigste für ein Solo-SaaS unter 10 GB. Supabase Pro für $25/Monat ist ohne Bundle wettbewerbsfähig. PlanetScale Scaler Pro für $39/Monat ist etwa 2x Neon; Enterprise für $399/Monat ist der Punkt, an dem PlanetScale keine Option für Solo-Entwickler mehr ist.

Die versteckten Kosten: Bundle-Preise

Supabases aufsehenerregende $25/Monat gelten nur für die Datenbank allein. Wenn Sie Supabase Auth, Storage und Realtime hinzufügen, zahlen Sie mindestens $99/Monat. Das ist wettbewerbsfähig mit Clerk + Postgres + S3 für ein kleines SaaS, aber nicht „günstig" im Vergleich zu Neon + Better Auth + R2, was bei etwa $40–$50/Monat für denselben Stack liegt. Für die Auth-Seite empfehle ich Auth0 vs Clerk vs Roll-Your-Own: SaaS Auth Cost and Control Compared.

Produktionscode: Neon + Drizzle in TanStack Start

Der TanStack-Ship-Starter wird mit vorkonfiguriertem Drizzle ORM ausgeliefert. Hier ist die eigentliche db.ts, leicht bereinigt:

// src/lib/db.ts — TanStack Ship Starter (Neon)
import { drizzle } from "drizzle-orm/neon-http";
import { neon } from "@neondatabase/serverless";
import * as schema from "./schema";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql, { schema });

export async function getUser(id: string) {
  const rows = await db
    .select()
    .from(schema.users)
    .where(eq(schema.users.id, id))
    .limit(1);
  return rows[0] ?? null;
}

Die zugehörige Schema-Datei verwendet Standard-Drizzle-Tabellendefinitionen:

// src/lib/schema.ts
import { pgTable, uuid, text, timestamp, jsonb } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: uuid("id").primaryKey().defaultRandom(),
  email: text("email").notNull().unique(),
  name: text("name"),
  metadata: jsonb("metadata").$type<Record<string, unknown>>(),
  createdAt: timestamp("created_at").defaultNow().notNull(),
});

Dies ist derselbe Code, der in Produktion auf vier meiner sieben Apps läuft. Der Neon-HTTP-Treiber ist Edge-nativ – jede Anfrage ist ein einzelner Round-Trip zum regionalen Neon-Proxy. Die vollständige Verdrahtung finden Sie im TanStack Ship Starter und in der Drizzle ORM-Dokumentation.

Wann jede Datenbank tatsächlich gewinnt

Neon gewinnt für Solo-Entwickler auf Cloudflare Workers (Cold-Start standardmäßig korrekt, niedrigste Preise, Branching eine Konfigurationsdatei entfernt); für Postgres mit dem geringsten operativen Aufwand (kein Connection Pooling oder Vacuum-Zeitpläne bei Neon nach meiner Erfahrung); und für bursty Workloads (Webhook-Empfänger, geplante Berichte – Skalierung auf null ist ein echter Kostenvorteil).

Supabase gewinnt, wenn Sie Auth + Storage + Realtime in einem Panel benötigen (das Bundle spart eine Woche); wenn Postgres Row-Level Security (RLS) die primäre Autorisierungsschicht ist; und wenn Sie am ersten Tag ein Admin-Dashboard benötigen (Supabase Studio ist gut für nicht-technische Benutzer).

PlanetScale gewinnt für Write-intensive Workloads (Vitess-Sharding verarbeitet Write-Durchsatz, der einen einzelnen Postgres-Node schmelzen würde); für Schemaänderungen ohne Ausfallzeit auf großen Tabellen (Online DDL über gh-ost ist Best-in-Class); und für Teams mit einem DBA, der Deploy-Request-Reviews möchte.

PlanetScale ist MySQL, nicht Postgres. Wenn Ihr SaaS Postgres-spezifische Features verwendet (JSONB-Operatoren, partielle Indizes, tsvector Volltextsuche), sind die Migrationskosten nicht trivial. Das habe ich bei einem 2024er Projekt gelernt; wir schätzten zwei Wochen und es dauerte sechs.

Für andere Datenbank-Backends empfehle ich Cloudflare D1 vs Postgres in Production und Usage Metering: ClickHouse vs Postgres.

Die ehrliche Entscheidungsmatrix

Für den TanStack-Ship-Starter ist die Standardkombination Cloudflare D1 für Hot Paths (Auth, Sessions, Billing) und Neon für Cold Paths (Analytics, Audit-Logs, große Joins). Diese Kombination deckt etwa 80 % der Solo-SaaS-Workloads ab und hält die Rechnung unter $50/Monat bei 10k MAU. Siehe TanStack Ship Features und die Preisseite.

Häufig gestellte Fragen

Ist Neon produktionsreif für zahlende Kunden? Ja – ich betreibe vier Produktions-SaaS-Apps auf Neon. Die Einschränkung ist der 480ms-Cold-Start-p99; wenn Ihre Benutzer sensibel sind, bleiben Sie beim Launch-Tier mit Always-On-Compute.

Funktioniert Supabases Free-Tier für Produktion? Für Prototyping, ja. Für zahlende Kunden, nein – der 1.200ms-Cold-Start-p99 wird in Ihren Dashboards auftauchen. Pro-Tier ($25/Monat) ist die Untergrenze.

Kann ich später von Supabase zu Neon migrieren? Ja. Beide sind Postgres; die Migration ist pg_dump + pg_restore plus ein IAM-Wechsel. Jede Migration dauerte bei mir etwa einen Tag.

Unterstützt PlanetScale serverlose Treiber wie Neon? Ja, über PlanetScale Boost. Cold-Start ist wettbewerbsfähig; der Einstiegspreis ($39/Monat) ist höher als Neons $19/Monat Launch.

Kann ich TanStack Ship mit allen dreien verwenden? Ja – Drizzle unterstützt Postgres und MySQL. Ändern Sie den Connection String und die Dialekt-Importe; der App-Code ändert sich nicht. Der Starter wird mit Neon als Standard ausgeliefert und enthält Supabase- und PlanetScale-Adapter unter /examples.

Was ist mit Cloudflare D1? D1 ist exzellent und bis 5 GB kostenlos für Hot Paths. Für Analytics, Audit-Logs und Workloads, die mehr als 10 GB benötigen, brauchen Sie Postgres. TanStack Ship verwendet standardmäßig D1 + Neon.