Neon vs PlanetScale vs Turso: Postgres, MySQL oder SQLite am Edge?

Die Neon vs PlanetScale vs Turso-Entscheidung läuft auf drei grundlegend verschiedene Wetten hinaus: Postgres, MySQL/Vitess und SQLite am Edge. Die Landschaft hat sich im vergangenen Jahr dramatisch verändert -- Databricks übernahm Neon für ca. 1 Mrd. $, PlanetScale startete Postgres-Unterstützung, und Turso hat Scale-to-Zero abgekündigt. Wenn du 2026 eine serverlose Datenbank auswählst, ist wahrscheinlich jeder Vergleich, den du bisher gelesen hast, veraltet.

Neon vs PlanetScale vs Turso auf einen Blick

Wähle Neon, wenn du volle Postgres-Kompatibilität, ein großzügiges Free Tier und die beste Vercel-Integration willst. Wähle PlanetScale, wenn du MySQL in Enterprise-Maßstab mit horizontalem Sharding benötigst. Wähle Turso, wenn Edge-Latenz und Multi-Tenant-Datenbankarchitekturen (eine Datenbank pro Nutzer) am wichtigsten sind.

Das war die Kurzversion. Der Rest dieses Artikels erklärt genau, warum jede Zelle so aussieht wie sie aussieht.

Wie funktioniert jede Datenbank unter der Haube?

Die Engine unter jeder Plattform beeinflusst alles von der Abfragesyntax bis hin zu Skalierungsgrenzen. Das Verständnis der Architektur hilft dir vorherzusagen, wie sich jede beim Wachstum deiner App verhält.

Neon: Serverless Postgres mit Branching

Neon trennt Compute vollständig vom Storage. Deine Postgres-Compute-Knoten sind ephemer -- sie starten, wenn eine Abfrage eintrifft, und skalieren herunter (oder auf null), wenn sie inaktiv sind. Der Storage befindet sich auf einer separaten pageserver-Ebene, die Haltbarkeit und Point-in-Time-Recovery übernimmt.

Diese Architektur ermöglicht Neons herausragendes Feature: Copy-on-Write-Branching. Einen Datenbankbranch zu erstellen ist nahezu sofort, unabhängig von der Größe, da keine Daten kopiert werden -- es werden Storage-Seiten mit dem Parent geteilt und nur neue Seiten geschrieben, wenn sich Daten ändern. Denke an git branch für deine Datenbank.

• Vollständiges PostgreSQL-Drahtprotokoll (pg_dump, psql, alles funktioniert)
• Autoscaling Compute von 0,25 bis 56 CU
• Eingebautes Connection Pooling über PgBouncer
• Neons Architektur verwendet Safekeepers für Write-Ahead-Log-Haltbarkeit

PlanetScale: Vitess-getriebenes MySQL (und jetzt Postgres)

PlanetScale läuft auf Vitess, der MySQL-Clustering-Engine, die ursprünglich bei YouTube gebaut wurde, um ihre Datenbank über Zehntausende von Knoten zu sharden. Wenn du horizontale Skalierung für MySQL benötigst, ist Vitess die am meisten kampferprobte Lösung, die es gibt.

PlanetScales Signature-DX-Feature sind Deploy Requests -- im Wesentlichen Pull Requests für Schemaänderungen. Du schlägst eine Migration vor, überprüfst den Diff und wendest sie ohne Downtime an. Kein Locking, keine Wartungsfenster.

Seit September 2025 bietet PlanetScale auch verwaltetes Postgres an. Es ist ein anderes Produkt als ihr Vitess-Angebot -- Single-Node-Postgres-Datenbanken ab 5 €/Mo. Horizontales Sharding für Postgres (genannt "Neki") ist noch in Entwicklung.

Für einen tieferen Einblick, wann Postgres mehr Sinn macht als MySQL (und umgekehrt), schau dir unseren PostgreSQL vs MySQL-Vergleich an.

• Vitess: horizontales Sharding, Zero-Downtime-Schema-Migrationen
• Postgres: Single-Node, produktionsreif, aber noch ohne Sharding
• Deploy Requests für sichere, überprüfbare Schemaänderungen
• Kein Scale-to-Zero -- Datenbanken laufen immer

Turso: SQLite am Edge mit libSQL

Turso verfolgt einen völlig anderen Ansatz. Anstatt eine serverbasierte Datenbank zu betreiben, verwendet es libSQL -- einen Open-Source-Fork von SQLite mit Server-Modus-Fähigkeiten. Deine Daten können am Edge leben, buchstäblich eingebettet in die Laufzeit deiner Anwendung.

Das Kernkonzept sind eingebettete Replikate: Lesereplikate, die innerhalb deines Anwendungsprozesses (oder an Edge-Standorten) mit Zero-Network-Latency-Lesevorgängen laufen. Schreibvorgänge gehen zu einer primären Instanz und werden asynchron an Replikate weitergegeben.

• libSQL erweitert SQLite um HTTP-Zugriff, Replikation und Multi-Tenancy
• Datenbank-pro-Nutzer-Modell unterstützt Tausende von isolierten Datenbanken
• Schreibvorgänge werden in Millisekunden vom Primär zu Replikaten weitergegeben
• Ideal für leseintensive, global verteilte Apps

Fazit: Neon gewinnt in Sachen Architekturbreite. Vollständiges Postgres mit sofortigem Branching deckt den größten Anwendungsbereich ab. PlanetScale gewinnt, wenn du speziell horizontales Sharding auf Vitess-Niveau benötigst. Turso gewinnt, wenn du Daten am Edge brauchst.

Wie verhalten sie sich bei Performance und Latenz?

Performance ist die Frage, die Entwickler zuerst stellen, und die Antwort hängt vollständig davon ab, ob deine Datenbank warm oder kalt ist.

Cold-Start-Realitätscheck

Neon ist die einzige der drei, die standardmäßig noch Scale-to-Zero durchführt. Wenn dein Compute-Knoten aus dem Idle aufwacht, erwarte 400–750 ms bei der ersten Abfrage. Nachfolgende Abfragen sind schnell. Du kannst Cold Starts eliminieren, indem du eine Mindest-Compute-Größe einstellst (0,25 CU kostet ca. 7 €/Mo).

PlanetScale war immer always-on -- keine Cold Starts, Punkt. Deine Datenbank läuft, egal ob jemand sie abfragt oder nicht.

Turso hat Scale-to-Zero für neue Nutzer eingestellt im Januar 2025. Neue Anmeldungen erhalten always-on-Instanzen, was keine Cold Starts bedeutet, aber auch keine "zahle nichts im Idle"-Einsparungen.

Edge-Latenz: Wo Turso glänzt

Für heiße Abfragen sind alle drei schnell. Aber Tursos eingebettete Replikate liefern etwas, das die anderen beiden nicht können: einstellige Millisekunden-Lesevorgänge am Edge. Wenn dein SQLite-Replikat im selben Cloudflare Worker oder Vercel Edge Function wie dein Code lebt, gibt es für Lesevorgänge überhaupt keinen Netzwerk-Hop.

Benchmark-Daten von Pilcrow (Juli 2023 -- als Richtungsgeber behandeln, nicht als aktuell) zeigten PlanetScale HTTP bei ca. 8 ms, Neon HTTP bei ca. 5 ms und Turso HTTP bei ca. 27 ms für zentralisierte Abfragen. Diese Zahlen stammen aus der Zeit vor PlanetScales Postgres-Launch und Tursos Infrastrukturänderungen, also als Referenzpunkte behandeln.

Fazit: Turso gewinnt bei Edge-Latenz. Eingebettete Replikate mit Zero-Network-Hop-Lesevorgängen sind unübertroffen. Für zentralisierte Workloads ohne Cold-Start-Bedenken ist PlanetScales always-on-Konsistenz schwer zu schlagen. Neons Cold Starts sind der Kompromiss für Scale-to-Zero-Einsparungen.

Was kostet jede Datenbank wirklich?

Hier fallen die meisten Vergleiche kurz -- sie listen Planpreise auf, ohne zu berechnen, was eine echte App zahlen würde. Lass uns das korrigieren.

Free Tier im Überblick

PlanetScale hat sein kostenloses Hobby-Tier im April 2024 abgeschafft. Der günstigste Einstiegspunkt ist jetzt 5 €/Mo für eine Single-Node-Postgres-Datenbank. Für Vitess/MySQL-Datenbanken ist die Preisgestaltung cluster-basiert und deutlich höher.

Reale Monatskosten auf vier Skalierungsebenen

Diese Schätzungen verwenden aktuelle Preise von 2026 von den offiziellen Preisseiten jeder Plattform. Tatsächliche Kosten variieren je nach Nutzungsmustern.

Ein paar Dinge fallen auf. Turso ist bei den niedrigen und mittleren Ebenen bemerkenswert günstig, da sein Zeilenlesevorgangs-Preismodell leseintensive Apps begünstigt. Neons nutzungsbasierte Preisgestaltung bedeutet, dass du nur für das zahlst, was du verbrauchst -- inaktive Datenbanken kosten im Free Tier nichts. PlanetScales Preisgestaltung ist für Postgres Single-Nodes wettbewerbsfähig, eskaliert aber mit Vitess-Clustern.

Die PlanetScale-Preisklippe

PlanetScales größte Schwäche für Solo-Entwickler: Es gibt kein Free Tier. Du gehst von 0 € (bei einem Konkurrenten) auf mindestens 5 €/Mo. Für finanzierte Startups ist das irrelevant, aber für Nebenprojekte und Prototyping sind Neon und Tursos Free Tiers deutlich besser.

Auf der anderen Seite bietet PlanetScales Vitess-Angebot horizontales Sharding, das weder Neon noch Turso erreichen können. Wenn dein Schreibdurchsatz Sharding erfordert, ist die Prämie gerechtfertigt.

Fazit: Neon gewinnt für die meisten Budgets. Das Free Tier plus nutzungsbasierte Preisgestaltung ist das flexibelste Modell. Tursos Zeilenlesevorgangs-Preisgestaltung ist ausgezeichnet für leseintensive Apps. PlanetScale kostet am unteren Ende mehr, bietet aber Enterprise-Grade-Skalierung.

Wie ist die Entwicklererfahrung?

Die tägliche DX ist wichtiger als Benchmark-Zahlen. Hier vergleichen die drei auf den Features, die du tatsächlich nutzen wirst.

Datenbank-Branching und CI/CD

Neons Copy-on-Write-Branching ist der Goldstandard. Erstelle einen Branch für jeden PR, führe Migrationen dagegen aus, teste mit produktionsähnlichen Daten und merge. Die Vercel-Integration erstellt automatisch einen Branch pro Preview-Deployment.

PlanetScales Deploy Requests sind eine andere Variante derselben Idee. Anstatt die gesamte Datenbank zu branchen, branchst du das Schema. Schlage eine Migration vor, überprüfe den Diff und wende ihn ohne Downtime an. Es ist meinungsbasierter, aber für Schemaänderungen im Maßstab wohl sicherer.

Turso hat kein Branching. Du verwaltest Migrationen mit Standard-SQLite-Tools.

ORM-Kompatibilitätsmatrix

Neon und PlanetScales Postgres-Angebot funktionieren sofort mit dem gesamten Postgres-ORM-Ökosystem. Turso erfordert libSQL-spezifische Adapter, die gut gepflegt, aber enger sind.

CLI und lokale Entwicklung

Alle drei haben solide CLIs: neonctl für Neon, pscale für PlanetScale und turso für Turso. Jedes unterstützt das Erstellen von Datenbanken, die Verwaltung von Branches (wo anwendbar) und die Verbindung vom Terminal aus.

Für die lokale Entwicklung glänzen Neon-Branches -- du kannst gegen einen Branch entwickeln, der Produktionsdaten widerspiegelt, ohne die Produktion zu berühren. PlanetScales Development Branches dienen einem ähnlichen Zweck. Turso läuft SQLite lokal, also ist die lokale Entwicklung ganz einfach -- zeige einfach auf eine lokale .db-Datei.

Fazit: Neon gewinnt bei der Entwicklererfahrung. Copy-on-Write-Branching mit Vercel-Integration ist die beste CI/CD-Geschichte. PlanetScales Deploy Requests sind ausgezeichnet für Teams, die Schema-Level-Überprüfung wünschen. Tursos Einfachheit ist unterschätzt, fehlt aber Branching.

Verbindung von Next.js -- Side-by-Side-Code

Hier sieht es aus, wie die Verbindung zu jeder Datenbank von einer Next.js-API-Route oder einem Server Component aussieht. Diese sind kopierfertig.

Rohe Treiber-Verbindung (alle drei)

Neon mit @neondatabase/serverless:

// lib/neon.ts
import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);

// Funktioniert in Edge Runtime und Node.js
export async function getActiveUsers() {
  const users = await sql`
    SELECT * FROM users WHERE active = true
  `;
  return users;
}

PlanetScale mit @planetscale/database:

// lib/planetscale.ts
import { connect } from "@planetscale/database";

const conn = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});

// Funktioniert in Edge Runtime und Node.js
export async function getActiveUsers() {
  const results = await conn.execute(
    "SELECT * FROM users WHERE active = true"
  );
  return results.rows;
}

Turso mit @libsql/client:

// lib/turso.ts
import { createClient } from "@libsql/client";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Funktioniert in Edge Runtime und Node.js
export async function getActiveUsers() {
  const result = await turso.execute(
    "SELECT * FROM users WHERE active = 1"
  );
  return result.rows;
}

Beachte, dass Turso = 1 statt = true verwendet -- SQLite hat keinen nativen Boolean-Typ. Kleiner Unterschied, aber er überrascht viele.

Drizzle ORM Setup (alle drei)

Wenn du Drizzle verwendest (und das solltest du wahrscheinlich für typsichere Abfragen), hier ist die Konfiguration für jede:

// drizzle.config.ts — Neon
import { neon } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-http";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);

// drizzle.config.ts — PlanetScale (MySQL/Vitess)
import { connect } from "@planetscale/database";
import { drizzle } from "drizzle-orm/planetscale-serverless";

const connection = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});
export const db = drizzle(connection);

// drizzle.config.ts — Turso
import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});
export const db = drizzle(turso);

Alle drei Treiber funktionieren in Vercel Edge Functions und Cloudflare Workers. Die API-Oberfläche ist ähnlich genug, dass der Wechsel zwischen ihnen meist ein Treibertausch ist -- dein Drizzle-Schema und deine Abfragen bleiben gleich (abzüglich der SQL-Dialektunterschiede).

Kann man mehrere serverlose Datenbanken zusammen nutzen?

Hier ist ein Muster, das in der Community an Zugkraft gewinnt, aber kein Vergleichsartikel spricht darüber: Turso für Edge-Lesevorgänge und Neon für Schreibvorgänge zu verwenden.

Die Idee ist einfach. Deine primären Daten leben in Neon (vollständiges Postgres, starke Konsistenz, reiche Abfrageunterstützung). Du replizierst leseintensive Daten zu Turso-Edge-Replikaten, die deinen Nutzern global nah sind. Lesevorgänge treffen Turso mit Sub-Millisekunden-Latenz; Schreibvorgänge gehen für Haltbarkeit und Konsistenz zu Neon.

Wann das sinnvoll ist:

• Global verteilte Apps, bei denen Leselatenz wichtig ist (Dashboards, Content-Plattformen)
• Multi-Tenant-SaaS, bei denen die leseintensiven Daten jedes Tenants vom Edge-Caching profitieren
• Apps mit einem 90/10-Lese/Schreib-Verhältnis, bei denen du leicht veraltete Lesevorgänge tolerieren kannst

Wann du es überspringen solltest:

• Die meisten Apps benötigen keine sub-10-ms-globalen Lesevorgänge -- eine Single-Region-Neon-Instanz reicht aus
• Die Komplexität des Betreibens zweier Datenbanken, Synchronisierens von Daten und Behandelns von Fehlern ist real
• Wenn deine App schreibintensiv ist, helfen Edge-Lesevorgänge kaum

Sei ehrlich mit dir selbst: Wenn du nicht auf globalem Maßstab mit strengen Latenzanforderungen operierst, fügt das Komplexität ohne nennenswerten Nutzen hinzu. Aber für die Apps, die es brauchen, ist es ein wirklich elegantes Muster.

Was hat sich 2025–2026 verändert? (Die drei großen Umwälzungen)

Jeder Konkurrenzvergleich wurde vor diesen Ereignissen geschrieben. Hier ist, was sich verändert hat und was das heute für deine Entscheidung bedeutet.

Neon + Databricks: Was die 1-Mrd.-$-Übernahme bedeutet

Im Mai 2025 übernahm Databricks Neon für ca. 1 Milliarde Dollar. Das war nicht nur ein finanzielles Ereignis -- es veränderte Neons Kurs.

Die unmittelbare Auswirkung: Neon senkte die Speicherkosten um 80 % (von 1,75 $ auf 0,35 $ pro GB-Monat). Die Vantage-Analyse legt nahe, dass dies teilweise durch Databricks' AWS-Mengenrabatte für Neon-Kunden entstand.

Das strategische Signal: Databricks stellte fest, dass 80 % der Neon-Datenbanken jetzt von KI-Agenten erstellt werden, gegenüber 30 % beim GA. Neon positioniert sich als Standarddatenbank für KI-gesteuerte Entwicklung -- automatisierte Schema-Erstellung, agentenverwaltete Daten, programmatische Datenbankbereitstellung.

Für dich als Entwickler bedeutet die Übernahme: günstigere Preise, Enterprise-Backing (Databricks ist profitabel) und eine zunehmend für programmatische/KI-Workflows optimierte Roadmap.

PlanetScale Postgres: MySQL ist nicht mehr die einzige Option

Im September 2025 startete PlanetScale Postgres-Unterstützung als GA. Das verändert vollständig das alte "Neon = Postgres, PlanetScale = MySQL"-Framing.

PlanetScale Postgres beginnt bei 5 €/Mo für Single-Node-Datenbanken mit Features wie Query Insights, Schema-Empfehlungen und Branching. Es ist produktionsreif und läuft bereits bei Hunderten von Unternehmen. Jedoch ist horizontales Sharding für Postgres (ihr "Neki"-Projekt) noch in Entwicklung.

Was das bedeutet: Wenn du zwischen Neon vs PlanetScale rein auf Engine-Präferenz wählst, deckt PlanetScale jetzt beides ab. Aber Neons Postgres ist ausgereifter (es ist seit Tag eins Postgres-nativ), hat ein Free Tier und bietet tieferes Branching mit Copy-on-Write-Semantik. PlanetScale Postgres ist es wert, im Auge zu behalten, aber Neon führt noch auf der Postgres-Seite.

Turso lässt Scale-to-Zero fallen: Always-On als Standard

Im Januar 2025 kündigte Turso bedeutende Plattformänderungen an: Scale-to-Zero für neue Nutzer abgekündigt, Infrastrukturkonsolidierung zu AWS und Edge-Replikate für neue Anmeldungen eingestellt.

Der Kompromiss ist klar: keine Cold Starts mehr (gut), aber keine "kostenlos im Idle"-Einsparungen mehr (weniger gut). Bestehende Nutzer mit Legacy-Plänen behalten Scale-to-Zero, aber alle anderen erhalten always-on-Instanzen.

Das macht Turso berechenbarer -- du wirst nicht von Cold-Start-Latenz überrascht -- aber es verringert auch den Abstand zwischen Turso und PlanetScale in der "serverless"-Dimension. Beide sind jetzt always-on verwaltete Datenbanken; Tursos Edge-Geschichte ist das, was es differenziert.

Neon vs PlanetScale vs Turso: Was solltest du wählen?

Genug Analyse. Hier ist der Entscheidungsrahmen.

Für die meisten Entwickler, die 2026 ein neues Projekt starten, ist Neon die Standardwahl. Free Tier, vollständiges Postgres, sofortiges Branching und Vercel-Integration decken 80 % der Anwendungsfälle ab. Du kannst jederzeit in bezahlte Pläne skalieren oder später wechseln -- das Postgres-Ökosystem bedeutet, dass du nie locked-in bist.

PlanetScale verdient seinen Platz, wenn du MySQL in Enterprise-Maßstab benötigst oder den Deploy Request Workflow für Zero-Downtime-Schemaänderungen in großen Teams willst.

Turso ist die richtige Wahl, wenn deine Architektur edge-first-Datenzugang oder Multi-Tenant-Datenbankisolation im Maßstab erfordert. Es ist ein spezialisiertes Tool, und es ist ausgezeichnet in dem, worauf es sich spezialisiert.

Wie Techsy die Auswahl serverloser Datenbanken angeht

Wir evaluieren serverlose Datenbanken für jedes Kundenprojekt in vier Dimensionen: Datenmodellkomplexität, Teamgröße und SQL-Dialektpräferenz, Skalierungstrajektorie über die nächsten 12–18 Monate und Deployment-Plattform (Vercel, Cloudflare, AWS usw.).

Unser Standard-Stack für die meisten Projekte ist Neon + Drizzle + Next.js. Hier ist der Grund:

1. Postgres gibt uns das reichste Ökosystem -- JSON-Spalten, Volltextsuche, PostGIS, Erweiterungen
2. Neons Branching ordnet sich perfekt Preview-Deployments und CI-Pipelines zu
3. Das Free Tier lässt uns ohne Abrechnungsaufwand für frühphasige Kunden prototypisieren
4. Drizzles Typsicherheit erkennt Schema-Drift bevor es die Produktion trifft

Wenn wir Alternativen empfehlen:

• PlanetScale für Teams, die von bestehender MySQL-Infrastruktur migrieren, wo das Umschreiben von Abfragen nicht praktisch ist
• Turso für Kunden, die global verteilte, leseintensive Produkte bauen, bei denen Edge-Latenz eine messbare Geschäftskennzahl ist
• Manchmal ist die ehrliche Antwort "benutze einfach Supabase", wenn du Auth + Datenbank + Storage in einem verwalteten Paket brauchst

Brauchst du Hilfe bei der Auswahl der richtigen Datenbank für dein nächstes Projekt? Hole dir eine kostenlose Backend-Beratung.

FAQ

Ist Neon besser als PlanetScale?

Das hängt von deinen Bedürfnissen ab. Neon ist besser für Postgres-native Teams, bietet ein Free Tier und hat tieferes Datenbank-Branching mit Copy-on-Write-Semantik. PlanetScale ist besser für MySQL-Workloads in Enterprise-Maßstab mit Vitess-Sharding und Zero-Downtime-Deploy-Requests. Da PlanetScale jetzt auch Postgres anbietet, wird die Lücke kleiner -- aber Neons Postgres ist ausgereifter.

Was ist der Unterschied zwischen Neon und Turso?

Neon ist serverless PostgreSQL mit Compute-Storage-Trennung und sofortigem Branching. Turso ist SQLite-basiert (libSQL) mit eingebetteten Replikaten für Edge-Lesevorgänge. Wähle Neon für das vollständige Postgres-Ökosystem und Branching-Workflows. Wähle Turso für globale Niedriglatenz-Lesevorgänge und Multi-Tenant-Datenbank-pro-Nutzer-Architekturen.

Ist PlanetScale ohne Free Tier noch es wert?

Für Hobby-Projekte wahrscheinlich nicht -- Neon und Turso bieten beide großzügige Free Tiers. Für finanzierte Startups und Unternehmen, die Vitess-betriebenes horizontales Sharding oder Zero-Downtime-Deploy-Requests benötigen, ist PlanetScales Preisgestaltung gerechtfertigt. Der 5-€/Mo-Postgres-Einstiegspunkt ist wettbewerbsfähig, aber nicht kostenlos.

Was ist die beste serverlose Datenbank für Next.js?

Neon für die meisten Entwickler. Es hat die tiefste Vercel-Integration (Branch pro Preview-Deployment), funktioniert mit allen Postgres-ORMs und beginnt kostenlos. Turso ist die Wahl, wenn du speziell globale Edge-Lesevorgänge benötigst. Alle drei haben Treiber, die in Vercel Edge Functions funktionieren.

Wie schlimm sind Neon Cold Starts in Produktion?

Erwarte 400–750 ms bei der ersten Abfrage, wenn Compute aus dem Idle aufwacht. Nachfolgende Abfragen sind schnell (einstellige ms). Für immer-reaktionsfähige Apps setze das Mindest-Compute auf 0,25 CU (ca. 7 €/Mo im Launch-Plan), um die Instanz warm zu halten und Cold Starts vollständig zu eliminieren.

Kann PlanetScale jetzt PostgreSQL verwenden?

Ja, seit September 2025. PlanetScale startete PostgreSQL-Unterstützung als GA, mit Single-Node-Datenbanken ab 5 €/Mo. Es ist produktionsreif mit Hunderten von Unternehmen, die darauf laufen. Jedoch ist horizontales Sharding für Postgres noch in Entwicklung -- dafür brauchst du ihr Vitess/MySQL-Angebot.

Ist Turso gut für Produktions-Apps?

Ja, mit Einschränkungen. Turso glänzt bei leseintensiven Workloads und Multi-Tenant-Architekturen. Die Schreib-Konkurrenz hat sich erheblich verbessert. Es eignet sich am besten für Apps mit hohem Lese-Schreib-Verhältnis und globalen Verteilungsanforderungen. Für schreibintensive Transaktions-Workloads sind Neon oder PlanetScale bessere Optionen.

Was ist mit PlanetScales Free Tier passiert?

PlanetScale entfernte sein Hobby (kostenloses) Tier im April 2024. Neue Hobby-Datenbanken wurden ab dem 6. März 2024 blockiert, und alle bestehenden wurden am 8. April 2024 eingestellt. Der günstigste Einstiegspunkt ist jetzt 5 €/Mo für eine Postgres-Single-Node-Datenbank. Das trieb viele Solo-Entwickler dazu, zu Neon oder Turso zu migrieren.

Wie wirkt sich die Databricks-Übernahme auf Neon aus?

Databricks übernahm Neon für ca. 1 Mrd. $ im Mai 2025. Seitdem hat Neon die Speicherkosten um 80 % gesenkt, in KI-Agenten-Workflows investiert und Enterprise-Glaubwürdigkeit gewonnen. Die Preise wurden günstiger, nicht teurer. Die Übernahme signalisiert langfristige Stabilität -- Databricks ist profitabel und zu Neon als seiner Postgres-Schicht verpflichtet.

Unterstützt Turso noch Scale-to-Zero?

Turso hat Scale-to-Zero für neue Nutzer Anfang 2025 eingestellt. Bestehende Nutzer mit Legacy-Plänen behalten es, aber neue Anmeldungen erhalten always-on-Instanzen. Das eliminiert Cold Starts, entfernt aber den "zahle nichts im Idle"-Vorteil. Edge-Replikate wurden für neue Nutzer ebenfalls im Rahmen der Plattformkonsolidierung eingestellt.

Welche serverlose Datenbank ist für ein Nebenprojekt am günstigsten?

Neon und Turso bieten beide Free Tiers, die die meisten Nebenprojekte abdecken. Neon gibt dir 0,5 GB Storage und 100 Compute-Stunden. Turso gibt dir 5 GB Storage und 500 Mio. Zeilenlesevorgänge. PlanetScale hat kein Free Tier -- das Minimum sind 5 €/Mo. Für ein typisches Nebenprojekt mit leichtem Traffic ist jedes Free Tier mehr als genug.

Abschließendes Fazit

Für die meisten Entwickler 2026 ist Neon die beste serverlose Datenbank für den Start. Es gibt dir das vollständige Postgres-Ökosystem, ein Free Tier, das für echte Projekte funktioniert, sofortiges Branching für CI/CD und Preise, die mit der Nutzung skalieren. Das Databricks-Backing fügt Enterprise-Stabilität ohne Enterprise-Lock-in hinzu.

PlanetScale verdient seinen Platz, wenn du horizontales MySQL-Sharding benötigst oder dein Team bereits im MySQL-Ökosystem investiert ist. Turso ist die richtige Wahl, wenn Edge-Latenz eine messbare Anforderung ist, nicht nur ein Nice-to-have.

Beurteile dein Datenmodell, deine Skalierungstrajektorie und wo deine Nutzer sind. Dann wähle eines und fang an zu bauen -- alle drei sind produktionsreif, und die Postgres/MySQL/SQLite-Ökosysteme bedeuten, dass du nie wirklich locked-in bist.

Quellen

• Neon Architekturübersicht
• Neon Preise
• PlanetScale Preise
• PlanetScale für Postgres ist jetzt GA
• Turso Preise
• Turso libSQL Dokumentation
• Databricks vereinbart Übernahme von Neon
• Bevorstehende Änderungen an der Turso-Plattform
• PlanetScale stellt den Hobby-Plan ein
• Serverless Database Latency Benchmarks -- Pilcrow (2023)
• Drizzle ORM -- Turso verbinden