Serverless Databases: Neon, Turso, and PlanetScale

The old answer to “where do I put my data” — provision a Postgres instance, manage connections, worry about cold starts — is increasingly obsolete for serverless infrastructure. In 2026, three serverless databases dominate the conversation: Neon (serverless Postgres), PlanetScale (MySQL on Vitess), and Turso (SQLite distributed at the edge). All three separate compute from storage and scale to zero when idle.

In this post, you will learn how each one works under the hood, when database branching genuinely helps, how to connect from a serverless runtime, and how to choose between Postgres, MySQL, and SQLite at the edge.

The fundamental problem: compute and storage are glued together

Traditional databases tie compute and storage to one machine. That means you pay for idle compute, and a serverless function that boots per-request can’t reuse a long-lived connection — a Postgres instance maxes out around 100–500 connections before overhead degrades performance. Serverless databases solve this by disaggregating compute from storage and exposing connection models built for connection-per-request patterns.

Feature	Neon	PlanetScale	Turso
Engine	PostgreSQL	MySQL (Vitess)	SQLite (libSQL)
Architecture	Branching Postgres	Vitess-based sharding	Edge-replicated SQLite
Scale to zero	Yes	Yes	Yes
Branching	Instant, excellent	Mature (deploy requests)	Manual/limited
Edge support	Regional (read replicas)	Regional	Native, 30+ regions
Free tier	512MB storage	None (removed 2024)	9GB, 500 databases

Neon: serverless Postgres with branching

Neon separates storage and compute. Your Postgres data lives in a distributed storage layer; compute (the Postgres process) spins up on demand and shuts down after inactivity. This enables:

1. Scale-to-zero — no compute, no cost when idle.
2. Instant branching — copy-on-write branches create a full database clone in seconds, perfect for per-PR staging environments.
3. Autoscaling — compute scales up on demand without migrating data.

The serverless driver speaks the Postgres protocol over HTTP, so you get Postgres semantics without the connection lifecycle overhead:

import { neon } from '@neondatabase/serverless';
const sql = neon(process.env.DATABASE_URL);

export async function getPosts() {
  return await sql`SELECT * FROM posts ORDER BY created_at DESC`;
}

Choose Neon if: you want full Postgres semantics and the ecosystem, per-PR branching for CI/CD, or you’re building a new Next.js SaaS on Vercel (Vercel Postgres is Neon). AI agent workloads are increasingly landing here too.

PlanetScale: MySQL at scale

PlanetScale is built on Vitess — the same sharding technology that powers YouTube’s MySQL. It handles connection multiplexing internally, making it friendly to serverless functions, and its schema branching is mature: deploy requests with visual diffs and no-downtime rollbacks. Note that the free tier was removed in 2024, so it’s the most expensive entry point of the three ($39/month minimum).

import { connect } from '@planetscale/database';

const config = {
  host: process.env.PLANETSCALE_HOST,
  username: process.env.PLANETSCALE_USERNAME,
  password: process.env.PLANETSCALE_PASSWORD,
};
const conn = await connect(config);

const results = await conn.execute('SELECT * FROM posts WHERE id = ?', [id]);

Choose PlanetScale if: you have an existing MySQL codebase, need horizontal sharding at enterprise scale, or need the most mature schema-branching workflow. It’s the strongest pick for multi-region active-active writes.

Turso: SQLite at the edge

Turso is the most architecturally different option. It runs libSQL, an open-source fork of SQLite, embedded in the process — which means there’s no connection lifecycle at all, and no cold starts. Read replicas are distributed across 30+ edge regions, bringing reads within ~15ms of users globally. The 500-database free tier enables the database-per-tenant pattern that no other provider offers cheaply.

import { createClient } from '@libsql/client';

const db = createClient({ url: process.env.TURSO_DATABASE_URL });
const result = await db.execute({ sql: 'SELECT * FROM posts WHERE id = ?', args: [id] });

SQLite’s limitations apply: no stored procedures, limited concurrent writes (single writer per database), and a simpler query planner. Writes go to the primary region and propagate to replicas.

Choose Turso if: edge latency is a measurable requirement, you’re building a multi-tenant app that can use one database per customer, or you want a local-first architecture where the embedded mode is a feature.

Branching for CI/CD: the killer feature

Database branching gives every pull request its own isolated, throwaway database — migrations run safely, and merges are tested against real data shapes. Neon’s branching is instant and cheap, making it the best-in-class for per-PR environments:

# Create a branch, run migrations, destroy it
neon branches create my-feature --parent main
neon branches destroy my-feature

The same logic is the core of PlanetScale’s deploy requests, which add visual diffs and no-downtime rollbacks for production migrations. Turso’s branching is manual and limited by comparison.

Cold starts and the connection model

Cold starts matter more than most people think. For most apps, Neon’s ~500ms cold start on the first request after idle is acceptable; for latency-sensitive APIs, keep minimum compute running or use Turso, which has no cold starts because SQLite is embedded. The HTTP/WebSocket drivers across all three are designed for connection-per-request patterns — which is exactly what serverless functions need.

Putting It All Together

A decision framework that covers most new projects:

• Neon — the default for 2026: full Postgres, a permanent free tier, instant branching, and tight serverless integration. Start here unless you have a reason not to.
• PlanetScale — MySQL at scale with mature branching and sharding. Right for existing MySQL teams or write-heavy enterprise workloads.
• Turso — edge-first SQLite for latency-critical reads and database-per-tenant architectures. The cheapest path to global read latency.

Conclusion & Next Steps

You now understand the three architectural bets — Postgres with branching, MySQL on Vitess, and SQLite at the edge — and how scale-to-zero, branching, and connection models work in each. Next steps: create a Neon free-tier branch and wire it to a Vercel function, try Turso’s embedded mode for a local-first prototype, and compare actual cold-start latency on a real device.

References / Sources

• Neon — serverless Postgres, architecture and branching. https://neon.tech/docs
• PlanetScale — MySQL/Vitess serverless database. https://planetscale.com/docs
• Turso — edge SQLite built on libSQL. https://turso.tech/docs
• pgvector for AI workloads on Postgres (related). https://github.com/pgvector/pgvector
• Neon serverless driver documentation. https://neon.tech/docs/serverless/serverless-driver