Serverless databases promise zero-downtime scaling, branching workflows, and pay-per-use pricing. PlanetScale, Turso, and Neon each take a different approach — MySQL, SQLite, and PostgreSQL respectively. Here's which serverless database fits your stack.
Quick Comparison
| PlanetScale | Turso | Neon | |
|---|---|---|---|
| Engine | MySQL (Vitess) | SQLite (libSQL) | PostgreSQL |
| Free tier | 5GB storage, 1B row reads | 9GB storage, 1B row reads | 0.5GB storage, 100 compute hrs |
| Branching | Excellent (database branches = git branches) | No branching (replicas instead) | Excellent (copy-on-write branches) |
| Edge | Limited | Excellent (25+ locations, embedded replicas) | Good (growing edge network) |
| Scale to zero | Yes (sleeps after inactivity) | N/A (SQLite is always ready) | Yes (auto-suspend) |
| Pricing model | Rows read + storage | Rows read + storage | Compute hours + storage |
PlanetScale — Git Workflows for Databases
PlanetScale is built on Vitess (YouTube's MySQL scaling layer). Its killer feature: database branching. Create a branch off your production schema, make changes, open a deploy request. Schema changes are automatically checked for compatibility before merging. This eliminates "works on my machine" database issues.
Best for: Teams that want database branching (schema as code), MySQL-compatible workloads, serverless apps with variable traffic.
Weak spot: MySQL engine (not Postgres — though many prefer Postgres). No edge deployment. Foreign key constraints are disabled by default (Vitess limitation).
Turso — SQLite at the Edge
Turso extends SQLite (via libSQL fork) to the edge. Your database is replicated across 25+ locations, and reads are served from the nearest replica. It's the best option for read-heavy, globally-distributed apps. SQLite compatibility means you can run the same DB locally during development.
Best for: Read-heavy apps, globally-distributed users, projects that want SQLite simplicity, edge computing (Cloudflare Workers, Vercel Edge).
Weak spot: SQLite engine (not full Postgres — limited extensions, no stored procedures). Single-primary writes (eventually consistent reads). No branching.
Neon — PostgreSQL, Serverless-Native
Neon makes PostgreSQL serverless: auto-suspend (scale to zero), instant copy-on-write branching, and a generous free tier. It's the closest to "Heroku Postgres but serverless." The branching model is excellent for preview environments — every PR gets its own database branch.
Best for: PostgreSQL workloads, preview/development database branching, serverless apps, teams that want the full Postgres feature set.
Weak spot: Smaller free compute (100 hours). Edge network is smaller than Turso's. Suspend/resume latency impacts cold starts.
Decision Matrix
| Scenario | Best Serverless DB |
|---|---|
| PostgreSQL app, full feature set | Neon |
| Edge-heavy, globally distributed | Turso |
| Database branching workflow | PlanetScale (MySQL) or Neon (Postgres) |
| SQLite at the edge | Turso |
| Most generous free tier | PlanetScale or Turso |
Bottom line: Neon for Postgres-first projects. Turso for edge/global SQLite. PlanetScale for MySQL workflows with database branching. All three have excellent free tiers — start there and scale when you need to. See also: Database Engine Comparison and Supabase vs Firebase vs Neon.