Serverless Databases: D1, Neon, and the New Landscape

Traditional databases assume long-lived connections from application servers. Serverless functions spin up, run, and die in milliseconds. This mismatch spawned a new category: serverless-native databases.

Cloudflare D1

D1 is SQLite at the edge. Your database runs in the same Cloudflare network as your Workers.

export default {
  async fetch(request, env) {
    const { results } = await env.DB.prepare(
      "SELECT * FROM posts WHERE published = 1 ORDER BY created_at DESC LIMIT 10"
    ).all();

    return Response.json(results);
  },
};

Strengths:

• Zero network latency from Workers (same network)
• SQLite’s full SQL support including JSON functions
• No connection pooling needed
• Free tier is generous (5GB storage, 5M reads/day)

Trade-offs:

• Single-region write primary (reads can be global)
• SQLite limitations (no stored procedures, limited concurrent writes)
• Still maturing for high-write workloads

Neon

Neon is serverless PostgreSQL. It separates compute from storage, allowing instant branching and scale-to-zero.

Strengths:

• Full PostgreSQL compatibility
• Branching (create a copy of your database for testing in seconds)
• Scale-to-zero (no charges when idle)
• Connection pooling built-in

Trade-offs:

• Cold starts when scaling from zero (~500ms)
• Network latency to the database region
• More complex pricing model

PlanetScale / Vitess

MySQL-compatible, built on Vitess (the technology behind YouTube’s database). Known for schema change workflows that don’t lock tables.

How to Choose

Factor	D1	Neon	PlanetScale
Engine	SQLite	PostgreSQL	MySQL
Edge latency	Lowest	Medium	Medium
SQL features	Good	Excellent	Good
Write scaling	Limited	Good	Excellent
Branching	No	Yes	Yes

Choose D1 when you’re on Cloudflare Workers and need low-latency reads with moderate writes.

Choose Neon when you need full PostgreSQL features, branching for dev/test workflows, or you’re using a Node.js-based serverless platform.

Choose PlanetScale when you need MySQL compatibility, horizontal write scaling, or non-blocking schema changes.

The serverless database space is moving fast. Evaluate against your actual query patterns and latency requirements, not feature checklists.