Turso vs PlanetScale vs Neon (2026)

TL;DR

Neon won the developer-first Postgres race in 2026 — branching, autoscale-to-zero, and the best DX. PlanetScale changed pricing in 2024 (killing the free tier), which drove many developers to Neon and Turso. Turso is the edge SQLite play — co-locate databases near users for sub-10ms reads, with the embedded replicas feature for literally running the database in your app process. For most SaaS apps: Neon (Postgres, generous free tier). For global edge apps needing low latency: Turso. PlanetScale: still solid for MySQL shops with branching workflows.

Key Takeaways

• Neon: serverless Postgres, branching per GitHub branch, autoscale-to-zero, generous free tier
• Turso: libSQL (SQLite fork), edge distribution, embedded replicas, Drizzle/LibSQL client
• PlanetScale: serverless MySQL, schema branching, free tier eliminated in 2024
• Pricing shift: PlanetScale's 2024 pricing change hurt adoption; Neon + Turso benefited
• For Next.js on Vercel: Neon (Postgres Serverless is the official Vercel partner)
• For edge functions: Turso (SQLite runs at the edge, Postgres doesn't)

---

Downloads

Package	Weekly Downloads	Trend
@neondatabase/serverless	~300K	↑ Fast growing
@libsql/client (Turso)	~200K	↑ Growing
@planetscale/database	~250K	↓ Declining

---

The Serverless Database Landscape in 2026

The serverless database market shifted dramatically in 2024 when PlanetScale eliminated its free tier, immediately directing thousands of developers toward Neon and Turso. That migration established competitive dynamics that continue to shape the market in 2026.

The fundamental question with serverless databases isn't "which is fastest" but "which architecture fits your deployment model." Traditional databases (Postgres, MySQL) require persistent connections — expensive in serverless environments where each function invocation is stateless. All three platforms in this comparison solve the connection problem differently, and those architectural choices determine which is right for your use case.

Neon runs Postgres with HTTP-based queries for serverless environments. Your code issues SQL over HTTP rather than persistent TCP connections, making it compatible with Vercel Edge Functions and Cloudflare Workers where TCP connections aren't available.

Turso uses libSQL, a fork of SQLite, which can literally run inside your serverless function as an embedded replica. Zero network latency for reads.

PlanetScale uses MySQL with Vitess under the hood (YouTube's horizontal scaling technology) and exposes an HTTP API for serverless compatibility.

---

Neon: Serverless Postgres

npm install @neondatabase/serverless
# Or use with Drizzle:
npm install drizzle-orm @neondatabase/serverless

// Neon serverless client (optimal for serverless/edge):
import { neon } from '@neondatabase/serverless';

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

// Works in Vercel Edge Functions (no persistent connection):
export async function GET(req: Request) {
  const rows = await sql`
    SELECT id, name, email FROM users
    WHERE plan = 'pro'
    ORDER BY created_at DESC
    LIMIT 10
  `;
  return Response.json(rows);
}

// With Drizzle ORM (recommended):
import { drizzle } from 'drizzle-orm/neon-http';
import { neon } from '@neondatabase/serverless';

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

// All Drizzle operations work:
const users = await db.select().from(usersTable).where(eq(usersTable.plan, 'pro')).limit(10);

Neon Branching

# Neon CLI:
npm install -g @neondatabase/cli
neonctl auth

# Create a branch for your PR:
neonctl branches create --name feature/new-user-schema

# Run migrations on the branch:
DATABASE_URL=$(neonctl branches get feature/new-user-schema --output json | jq -r '.connection_string') \
  npx drizzle-kit migrate

# Merge branch (after PR merges):
neonctl branches delete feature/new-user-schema

GitHub Actions integration:

- name: Create Neon branch
  uses: neondatabase/create-branch-action@v5
  with:
    project_id: ${{ vars.NEON_PROJECT_ID }}
    branch_name: preview/${{ github.event.pull_request.number }}
    api_key: ${{ secrets.NEON_API_KEY }}

- name: Run migrations on branch
  env:
    DATABASE_URL: ${{ steps.create-branch.outputs.db_url }}
  run: npx drizzle-kit migrate

Neon's branching system is its most compelling differentiator. The concept mirrors Git branching: each branch is a copy-on-write fork of the parent database that shares storage for unchanged data. Creating a branch takes under 1 second regardless of database size because no data is copied — only changes are written to the new branch. For teams with 5+ developers, being able to run database migrations against per-PR preview databases eliminates an entire class of "works on my branch" bugs that only appear when schema changes conflict.

Neon's autoscale-to-zero deserves mention. A Neon compute scales down to zero after a configurable idle period (default 5 minutes). The cold-start latency — the time to wake a sleeping compute — is ~500ms. For most applications, this is imperceptible. For latency-sensitive APIs, Neon's "always-active" mode keeps the compute warm at additional cost.

The Vercel partnership is practically significant: Vercel's marketplace integration means Neon databases can be provisioned directly from the Vercel dashboard with automated environment variable injection. For Next.js developers on Vercel, Neon is the path of least resistance.

Neon Pricing

Free tier:
  → 0.5 GB storage
  → 191.9 compute hours/month (autoscale-to-zero helps)
  → 1 project, 10 branches
  → Postgres 16

Launch: $19/month
  → 10 GB storage
  → 300 compute hours
  → Unlimited branches

Scale: $69/month
  → 50 GB storage
  → Compute scales automatically

---

Turso: Edge SQLite

npm install @libsql/client
# Or with Drizzle:
npm install drizzle-orm @libsql/client

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

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

// Execute SQL:
const result = await client.execute({
  sql: 'SELECT * FROM users WHERE plan = ? LIMIT 10',
  args: ['pro'],
});

// With Drizzle ORM:
import { drizzle } from 'drizzle-orm/libsql';
import { createClient } from '@libsql/client';

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

export const db = drizzle(client);

Turso Embedded Replicas (The Killer Feature)

// Embedded replica: database runs in your app process
// Reads hit local SQLite file, writes sync to Turso cloud:
import { createClient } from '@libsql/client';

const client = createClient({
  url: 'file:/tmp/mydb.sqlite',  // Local SQLite replica
  syncUrl: process.env.TURSO_DATABASE_URL,  // Sync from Turso
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Sync latest changes:
await client.sync();

// Reads: zero network latency (local file)
const fastRead = await client.execute('SELECT * FROM users WHERE id = ?', [userId]);

// Writes: go to Turso cloud, then sync back
await client.execute('UPDATE users SET plan = ? WHERE id = ?', ['pro', userId]);

Turso's embedded replicas represent a genuinely new architecture: your application reads from a local SQLite file that syncs from Turso's cloud. Read latency drops to sub-millisecond because there's no network round-trip. Writes go to the cloud and sync back asynchronously. For applications where reads vastly outnumber writes — product catalogs, blog platforms, configuration systems — this architecture produces latency numbers that no Postgres deployment can match.

The multi-tenant story is Turso's other differentiator. Turso allows 500 databases on the free tier and 10,000 on the Scaler plan ($29/month). For SaaS applications that need per-customer database isolation — a common pattern for security and compliance — Turso makes this economically viable. Doing the same with Postgres (Neon or otherwise) requires separate projects per tenant, which is expensive and operationally complex.

SQLite's limitations matter at scale: no concurrent writers (writes are serialized), limited data types compared to Postgres, and some advanced SQL features missing. For most CRUD applications these aren't barriers, but if your application does complex analytical queries or needs Postgres extensions (PostGIS, pgvector), SQLite isn't a fit.

Turso Pricing

Free tier:
  → 500 databases
  → 9 GB total storage
  → 1 billion row reads/month
  → 25 million row writes/month

Scaler: $29/month
  → 10,000 databases (multi-tenant!)
  → 24 GB storage
  → 10 GB network egress

---

PlanetScale: MySQL with Branching

npm install @planetscale/database

// PlanetScale client:
import { connect } from '@planetscale/database';

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

const results = await conn.execute('SELECT * FROM users WHERE plan = ?', ['pro']);

PlanetScale was the first serverless database to offer branching workflows, and it's still excellent at it. The schema change workflow — open a branch, make schema changes, create a deploy request, merge — mirrors Git pull requests and prevents the downtime that traditional ALTER TABLE migrations cause on large tables.

The 2024 free tier elimination was painful for developers who had built hobby projects on PlanetScale. The $39/month minimum price point is reasonable for production applications but makes PlanetScale less attractive for side projects and small teams. Neon's $19/month Launch plan offers comparable capabilities with the addition of Postgres (which many teams prefer over MySQL).

PlanetScale's MySQL base is still relevant for teams with existing MySQL investments: applications already using MySQL-compatible ORMs, teams with MySQL DBA expertise, and applications that rely on MySQL-specific features. The migration cost from MySQL to Postgres is non-trivial, and PlanetScale lets MySQL shops get serverless benefits without a database migration.

PlanetScale Pricing (2026)

⚠️  Free tier eliminated in March 2024

Scaler: $39/month
  → 10 GB storage
  → 1 billion row reads/month
  → 10 million row writes/month

For comparison, Neon ($19/mo) and Turso (free tier) are cheaper
for most startup use cases.

---

Comparison Table

	Neon	Turso	PlanetScale
Engine	PostgreSQL	SQLite (libSQL)	MySQL
Edge compatible	✅ (HTTP API)	✅ (native)	✅ (HTTP API)
Branching	✅	❌	✅
Embedded replicas	❌	✅	❌
Free tier	✅ Generous	✅ Very generous	❌ Eliminated 2024
Prisma support	✅	Limited	✅
Drizzle support	✅	✅	✅
Autoscale	✅ to zero	N/A	✅
Multi-tenant (per-user DB)	❌	✅ (500 free DBs)	❌
Starting price	$0 (free tier)	$0 (free tier)	$39/month

---

ORM Compatibility

All three databases work well with Drizzle ORM, which has become the preferred ORM for TypeScript projects in 2026. Drizzle's type-safe query builder generates SQL that's dialect-aware — you configure the Neon adapter, the LibSQL adapter, or the MySQL2 adapter, and the same schema definitions produce appropriate SQL for each platform.

Prisma's Turso support requires using the @prisma/adapter-libsql preview feature, which is less stable than Prisma's first-class Postgres and MySQL support. For Turso specifically, Drizzle is currently the more polished ORM integration.

---

Decision Guide

Choose Neon if:
  → Postgres is your standard
  → Next.js on Vercel (official partnership)
  → Need database branching for CI/CD
  → Free tier is important (most startup use)

Choose Turso if:
  → Multi-tenant SaaS needing per-user database
  → Global edge deployment with low read latency
  → SQLite is acceptable (most SQL features work)
  → Cloudflare Workers (libSQL runs at the edge)

Choose PlanetScale if:
  → MySQL is required (legacy code, existing data)
  → Schema branching workflow is already established
  → Budget for $39+/month
  → Not price-sensitive

---

Production Architecture: Migrations and Schema Management

Choosing a serverless database isn't just about query performance — it's about how you manage schema changes across development, staging, and production environments.

Neon Branch-Based Migrations

Neon's branching model enables a migrations workflow that mirrors Git branching: each feature branch gets a database branch, migrations run against the feature branch, and on PR merge, the migration runs against production. The feature branch database is then deleted.

This workflow eliminates the "migration works locally, breaks in staging" class of bugs. The staging environment is a Neon branch of production — it has the same data shape, the same constraints, and the same indexes. Drizzle-Kit's migration runner works identically against Neon branches:

# Feature branch development
DATABASE_URL=$(neonctl branches get feature/add-teams --output json | jq -r '.connection_uri') \
  npx drizzle-kit migrate

# CI — after PR merges to main
DATABASE_URL=$PRODUCTION_URL npx drizzle-kit migrate

Teams using Neon catch migration failures in PR preview environments rather than in production deployment windows — a significant reduction in on-call incidents.

PlanetScale's Deploy Requests

PlanetScale's schema branching predates Neon's branching by two years and solves a harder problem: running migrations on MySQL tables with millions of rows without downtime. PlanetScale's internal schema migration engine applies DDL changes online — new columns are added with backfills running in the background, foreign key constraints are validated asynchronously, and the migration only blocks writes for milliseconds when it completes.

For teams with large MySQL tables where ALTER TABLE ADD COLUMN would cause minutes of downtime, PlanetScale's migration infrastructure is genuinely superior to alternatives. The $39/month minimum is justified if you're managing production tables at that scale.

Turso and Schema Management

Turso's multi-database architecture means schema management multiplies with your tenant count. A SaaS with 1,000 customers on separate Turso databases needs to apply migrations to 1,000 databases simultaneously. Turso's Groups feature handles this:

# Apply migration to all databases in a group via Turso CLI
turso db shell --group production -- "ALTER TABLE users ADD COLUMN preferences TEXT"

For most schema changes, Turso Groups makes this manageable. The exception is data backfills — these need custom scripts that batch updates across all tenant databases.

ORM Migrations in 2026

Drizzle Kit is the recommended migration tool for all three platforms. Its TypeScript-first schema definitions generate migration SQL that's dialect-aware, and drizzle-kit push applies schema changes directly during development while drizzle-kit generate + drizzle-kit migrate provides the explicit migration file workflow needed for production.

How you structure your backend API layer affects how migrations are applied at startup. Both Hono and Elysia server startup sequences can run pending migrations automatically — useful for containerized deployments where the API server starts before any manual migration step. For Turso with 1,000 tenant databases, the startup migration pattern needs careful sequencing to avoid overwhelming the API with concurrent database operations.

Practical Tier Summary

For most SaaS applications building in 2026: start on Neon's free tier during development (10 branches, autoscale-to-zero, Postgres). Upgrade to Neon Launch ($19/month) when you have real users. Consider Turso when your architecture genuinely needs per-tenant database isolation or when edge-global read latency is a customer requirement. Only consider PlanetScale if your team has existing MySQL investments and is comfortable with the $39/month floor.

---

Connection Pooling, Pricing Cliffs, and Production Considerations

Serverless databases have fundamentally different operational characteristics from traditional hosted databases, and the differences matter most under production traffic patterns.

The Connection Limit Problem

Traditional PostgreSQL has a hard limit on simultaneous database connections — typically 100 for small instances. Serverless functions create a new connection per invocation, meaning 100 concurrent function calls equals 100 database connections. This works for low-traffic applications but becomes catastrophic at scale: a traffic spike that generates 500 concurrent requests exhausts PostgreSQL's connection pool and cascades into timeout failures.

All three platforms address this differently. Neon's serverless driver uses WebSocket connections that share a pool managed by Neon's infrastructure. A single Neon connection pool can handle hundreds of simultaneous JavaScript requests. PlanetScale uses its Vitess proxy layer to pool connections automatically — clients connect to PlanetScale's proxy, which maintains a much smaller pool to the underlying MySQL database. Turso's libSQL server model handles connections at the server level; edge deployments use HTTP endpoints that avoid persistent connection state entirely.

For Next.js applications deployed on Vercel, Neon's Vercel integration configures connection pooling automatically. You get a pooled connection string and a direct connection string (for migrations) in your environment variables. This eliminates the PgBouncer configuration step that traditional Postgres deployments require.

Pricing Cliffs and Cost Modeling

Serverless pricing models look appealing in development but can create surprises in production. All three platforms have free tiers, but the step-functions in paid plans differ significantly.

Neon's free tier includes 0.5GB storage and 191.9 compute hours per month (roughly enough for a moderate hobby project). The first paid plan ($19/month) adds storage and compute proportionally. Neon's autoscale model means you pay for what you use — a database that handles 10 QPS costs meaningfully less than one handling 1,000 QPS.

Turso's pricing is per-database. The free tier allows 500 databases (generous for multi-tenant applications) and 9GB total storage. For applications using per-user SQLite databases, this pricing model is excellent — isolation without connection multiplexing complexity.

PlanetScale's pricing changed significantly in 2024 when they eliminated the free tier and repositioned as an enterprise database. Starting at $39/month, PlanetScale prices itself above where most individual developers and small teams operate, but below where most enterprises hesitate.

Data Branching in Practice

Neon's branch feature is its most distinctive capability for development workflows. Creating a branch takes milliseconds and copies the schema and data (using copy-on-write internally) without actually duplicating storage. A branch that diverges by 100 rows from its parent uses only the storage for those 100 rows — not a full database copy.

This enables a development workflow where each pull request gets its own database branch, tests run against isolated data, and merging the PR deletes the branch automatically. Neon's GitHub integration can automate this with minimal configuration. For teams practicing trunk-based development with frequent merges, database branching reduces the testing impediment of shared staging databases.

PlanetScale's deploy requests (their equivalent of database branching for schema changes) solve a different problem: safely deploying breaking schema changes in production. By running both the old and new schema simultaneously during a migration window, PlanetScale eliminates downtime for schema changes. This is more relevant for teams with complex migrations than for early-stage applications.

Compare database package health on PkgPulse. Related: Best Database Migration Tools for Node.js and Best JavaScript Package Managers 2026.