Neon vs PlanetScale vs Turso: Postgres, MySQL, or SQLite at the Edge?

The Neon vs PlanetScale vs Turso decision boils down to three fundamentally different bets: Postgres, MySQL/Vitess, and SQLite at the edge. The landscape shifted dramatically over the past year, Databricks acquired Neon for ~$1B, PlanetScale launched Postgres support, and Turso deprecated scale-to-zero. If you're choosing a serverless database in 2026, every comparison you've read is probably outdated.

Neon vs PlanetScale vs Turso at a Glance

Pick Neon if you want full Postgres compatibility, a generous free tier, and the best Vercel integration. Pick PlanetScale if you need MySQL at enterprise scale with horizontal sharding. Pick Turso if edge latency and multi-tenant database-per-user architectures matter most.

That's the quick version. The rest of this article breaks down exactly why each cell looks the way it does.

How Does Each Database Work Under the Hood?

The engine under each platform shapes everything from query syntax to scaling limits. Understanding the architecture helps you predict how each will behave as your app grows.

Neon: Serverless Postgres With Branching

Neon separates compute from storage completely. Your Postgres compute nodes are ephemeral, they spin up when a query arrives and scale down (or to zero) when idle. Storage lives on a separate pageserver layer that handles durability and point-in-time recovery.

This architecture enables Neon's killer feature: copy-on-write branching. Creating a database branch is nearly instant regardless of size because it doesn't copy data, it shares storage pages with the parent and only writes new pages when data changes. Think git branch for your database.

• Full PostgreSQL wire protocol (pg_dump, psql, everything works)
• Autoscaling compute from 0.25 to 56 CU
• Built-in connection pooling via PgBouncer
• Neon's architecture uses safekeepers for write-ahead log durability

PlanetScale: Vitess-Powered MySQL (and Now Postgres)

PlanetScale runs on Vitess, the MySQL clustering engine originally built at YouTube to shard their database across tens of thousands of nodes. If you need horizontal scaling for MySQL, Vitess is the most battle-tested solution in existence.

PlanetScale's signature DX feature is deploy requests, essentially pull requests for schema changes. You propose a migration, review the diff, and apply it with zero downtime. No locking, no maintenance windows.

Since September 2025, PlanetScale also offers managed Postgres. It's a different product from their Vitess offering, single-node Postgres databases starting at $5/mo. Horizontal sharding for Postgres (called "Neki") is still in development.

For a deeper dive on when Postgres makes more sense than MySQL (and vice versa), check out our PostgreSQL vs MySQL comparison.

• Vitess: horizontal sharding, zero-downtime schema migrations
• Postgres: single-node, production-ready, but without sharding yet
• Deploy requests for safe, reviewable schema changes
• No scale-to-zero, databases are always running

Turso: SQLite at the Edge With libSQL

Turso takes a completely different approach. Instead of running a server-based database, it uses libSQL, an open-source fork of SQLite with server-mode capabilities. Your data can live at the edge, literally embedded in your application's runtime.

The core concept is embedded replicas: read replicas that run inside your application process (or at edge locations) with zero-network-latency reads. Writes go to a primary instance and propagate to replicas asynchronously.

• libSQL extends SQLite with HTTP access, replication, and multi-tenancy
• Database-per-user model supports thousands of isolated databases
• Writes propagate from primary to replicas in milliseconds
• Ideal for read-heavy, globally distributed apps

Verdict: Neon wins for architecture breadth. Full Postgres with instant branching covers the widest range of use cases. PlanetScale wins if you specifically need Vitess-grade horizontal sharding. Turso wins if you need data at the edge.

How Do They Compare on Performance and Latency?

Performance is the question developers ask first, and the answer depends entirely on whether your database is warm or cold.

Cold Start Reality Check

Neon is the only one of the three that still does scale-to-zero by default. When your compute node wakes from idle, expect 400-750ms on the first query. Subsequent queries are fast. You can eliminate cold starts by setting a minimum compute size (0.25 CU costs roughly $7/mo).

PlanetScale has always been always-on, no cold starts, period. Your database is running whether or not anyone is querying it.

Turso deprecated scale-to-zero for new users in January 2025. New signups get always-on instances, which means no cold starts but also no "pay nothing when idle" savings.

Edge Latency: Where Turso Shines

For hot queries, all three are fast. But Turso's embedded replicas deliver something the other two can't: single-digit millisecond reads at the edge. When your SQLite replica lives in the same Cloudflare Worker or Vercel Edge Function as your code, there's no network hop for reads at all.

Benchmark data from Pilcrow (July 2023 -- treat as directional, not current) showed PlanetScale HTTP at ~8ms, Neon HTTP at ~5ms, and Turso HTTP at ~27ms for centralized queries. Independent benchmarks on Cloudflare Workers corroborated similar patterns. These numbers predate PlanetScale's Postgres launch and Turso's infrastructure changes, so take them as reference points rather than gospel.

Verdict: Turso wins for edge latency. Embedded replicas with zero-network-hop reads are unmatched. For centralized workloads without cold start concerns, PlanetScale's always-on consistency is hard to beat. Neon's cold starts are the tradeoff for scale-to-zero savings.

What Does Each Database Actually Cost?

This is where most comparisons fall short, they list plan prices without calculating what a real app would pay. Let's fix that.

Free Tier Breakdown

PlanetScale eliminated its free Hobby tier in April 2024. The cheapest entry point is now $5/mo for a single-node Postgres database. For Vitess/MySQL databases, pricing is cluster-based and significantly higher.

Real Monthly Cost at Four Scale Tiers

These estimates use current 2026 pricing from each platform's official pricing pages. Actual costs vary by usage patterns.

A few things jump out. Turso is remarkably cheap at the low and mid tiers because its row-read pricing model favors read-heavy apps. Neon's usage-based pricing means you only pay for what you consume, idle databases cost nothing on the free tier. PlanetScale's pricing is competitive for Postgres single-nodes but escalates with Vitess clusters.

The PlanetScale Pricing Cliff

PlanetScale's biggest weakness for solo developers: there's no free tier. You go from $0 (using a competitor) to $5/mo minimum. For funded startups this is irrelevant, but for side projects and prototyping, Neon and Turso's free tiers are meaningfully better.

On the flip side, PlanetScale's Vitess offering provides horizontal sharding that neither Neon nor Turso can match. If your write throughput demands sharding, the premium is justified.

Verdict: Neon wins for most budgets. The free tier plus usage-based pricing is the most flexible model. Turso's row-read pricing is excellent for read-heavy apps. PlanetScale costs more at the low end but delivers enterprise-grade scaling.

How Is the Developer Experience?

Day-to-day DX matters more than benchmark numbers. Here's how the three compare on the features you'll actually use.

Database Branching and CI/CD

Neon's copy-on-write branching is the gold standard. Create a branch for every PR, run migrations against it, test with production-like data, and merge. The Vercel integration creates a branch per preview deployment automatically.

PlanetScale's deploy requests are a different flavor of the same idea. Instead of branching the whole database, you branch the schema. Propose a migration, review the diff, and apply it with zero downtime. It's more opinionated but arguably safer for schema changes at scale.

Turso doesn't have branching. You manage migrations with standard SQLite tooling.

ORM Compatibility Matrix

Neon and PlanetScale's Postgres offering work with the entire Postgres ORM ecosystem out of the box. Turso requires libSQL-specific adapters, which are well-maintained but narrower.

CLI and Local Development

All three have solid CLIs: neonctl for Neon, pscale for PlanetScale, and turso for Turso. Each supports creating databases, managing branches (where applicable), and connecting from your terminal.

For local development, Neon branches shine, you can develop against a branch that mirrors production data without touching production. PlanetScale's development branches serve a similar purpose. Turso runs SQLite locally, so local dev is dead simple, just point at a local .db file.

Verdict: Neon wins for developer experience. Copy-on-write branching with Vercel integration is the best CI/CD story. PlanetScale's deploy requests are excellent for teams that want schema-level review. Turso's simplicity is underrated but lacks branching.

Connecting From Next.js, Side-by-Side Code

Here's what connecting to each database looks like from a Next.js API route or Server Component. These are copy-paste ready.

Raw Driver Connection (All Three)

Neon with @neondatabase/serverless:

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

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

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

PlanetScale with @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,
});

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

Turso with @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,
});

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

Notice Turso uses = 1 instead of = true, SQLite doesn't have a native boolean type. Small difference, but it catches people off guard.

Drizzle ORM Setup (All Three)

If you're using Drizzle (and you probably should for type-safe queries), here's the config for each:

// 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);

All three drivers work in Vercel Edge Functions and Cloudflare Workers. The API surface is similar enough that switching between them is mostly a driver swap, your Drizzle schema and queries stay the same (minus SQL dialect differences).

Can You Use Multiple Serverless Databases Together?

Here's a pattern that's gaining traction in the community but no comparison article talks about: using Turso for edge reads and Neon for writes.

The idea is straightforward. Your primary data lives in Neon (full Postgres, strong consistency, rich query support). You replicate read-heavy data to Turso edge replicas that sit close to your users globally. Reads hit Turso with sub-millisecond latency; writes go to Neon for durability and consistency.

When this makes sense:

• Globally distributed apps where read latency matters (dashboards, content platforms)
• Multi-tenant SaaS where each tenant's read-heavy data benefits from edge caching
• Apps with a 90/10 read/write ratio where you can tolerate slightly stale reads

When to skip it:

• Most apps don't need sub-10ms global reads, a single-region Neon instance is fine
• The complexity of maintaining two databases, syncing data, and handling failures is real
• If your app is write-heavy, edge reads don't help much

Be honest with yourself: if you're not operating at global scale with strict latency requirements, this adds complexity without meaningful benefit. But for the apps that need it, it's a genuinely elegant pattern.

What Changed in 2025-2026? (The Big Three Shakeups)

Every competitor comparison was written before these events. Here's what changed and what it means for your decision today.

Neon + Databricks: What the $1B Acquisition Means

In May 2025, Databricks acquired Neon for approximately $1 billion. This wasn't just a financial event, it changed Neon's trajectory.

The immediate impact: Neon cut storage costs by 80% (from $1.75 to $0.35 per GB-month). The Vantage analysis suggests this came partly from Databricks' AWS volume discounts flowing through to Neon customers.

The strategic signal: Databricks cited that 80% of Neon databases are now created by AI agents, up from 30% at GA. Neon is positioning itself as the default database for AI-driven development, automated schema creation, agent-managed data, programmatic database provisioning.

For you as a developer, the acquisition means: cheaper pricing, enterprise backing (Databricks is profitable), and a roadmap increasingly optimized for programmatic/AI workflows.

PlanetScale Postgres: MySQL Is No Longer the Only Option

In September 2025, PlanetScale launched Postgres support as GA. This completely changes the old "Neon = Postgres, PlanetScale = MySQL" framing.

PlanetScale Postgres starts at $5/mo for single-node databases with features like Query Insights, schema recommendations, and branching. It's production-ready and already running hundreds of companies. However, horizontal sharding for Postgres (their "Neki" project) is still in development.

What this means: if you're choosing between Neon vs PlanetScale purely on engine preference, PlanetScale now covers both. But Neon's Postgres is more mature (it's been Postgres-native from day one), has a free tier, and offers deeper branching with copy-on-write semantics. PlanetScale Postgres is worth watching but Neon still leads on the Postgres side.

Turso Drops Scale-to-Zero: Always-On by Default

In January 2025, Turso announced significant platform changes: scale-to-zero deprecated for new users, infrastructure consolidation to AWS, and edge replicas discontinued for new signups.

The tradeoff is clear: no more cold starts (good), but no more "free when idle" savings (less good). Existing users on legacy plans keep scale-to-zero, but everyone else gets always-on instances.

This makes Turso more predictable, you won't get surprised by cold start latency, but it also narrows the gap between Turso and PlanetScale on the "serverless" dimension. Both are now always-on managed databases; Turso's edge story is what differentiates it.

Neon vs PlanetScale vs Turso: Which Should You Pick?

Enough analysis. Here's the decision framework.

For most developers starting a new project in 2026, Neon is the default pick. Free tier, full Postgres, instant branching, and Vercel integration cover 80% of use cases. You can always scale into the paid plans or switch later, the Postgres ecosystem means you're never locked in.

PlanetScale earns its place when you need MySQL at enterprise scale or want the deploy request workflow for zero-downtime schema changes across large teams.

Turso is the right choice when your architecture demands edge-first data access or multi-tenant database isolation at scale. It's a specialized tool, and it's excellent at what it specializes in.

How Techsy Approaches Serverless Database Selection

We evaluate serverless databases across four dimensions for every client project: data model complexity, team size and SQL dialect preference, scaling trajectory over the next 12-18 months, and deployment platform (Vercel, Cloudflare, AWS, etc.).

Our default stack for most projects is Neon + Drizzle + Next.js. Here's why:

1. Postgres gives us the richest ecosystem, JSON columns, full-text search, PostGIS, extensions
2. Neon's branching maps perfectly to preview deployments and CI pipelines
3. The free tier lets us prototype without billing overhead for early-stage clients
4. Drizzle's type safety catches schema drift before it hits production

When we recommend alternatives:

• PlanetScale for teams migrating from existing MySQL infrastructure where rewriting queries isn't practical
• Turso for clients building globally distributed, read-heavy products where edge latency is a measurable business metric
• Sometimes the honest answer is "just use Supabase" when what you need is auth + database + storage in one managed package

Need help choosing the right database for your next project? Get a free backend consultation.

FAQ

Is Neon better than PlanetScale?

It depends on your needs. Neon is better for Postgres-native teams, offers a free tier, and has deeper database branching with copy-on-write semantics. PlanetScale is better for MySQL workloads at enterprise scale with Vitess sharding and zero-downtime deploy requests. Since PlanetScale now offers Postgres too, the gap is narrowing, but Neon's Postgres is more mature.

What is the difference between Neon and Turso?

Neon is serverless PostgreSQL with compute-storage separation and instant branching. Turso is SQLite-based (libSQL) with embedded replicas for edge reads. Choose Neon for the full Postgres ecosystem and branching workflows. Choose Turso for global low-latency reads and multi-tenant database-per-user architectures.

Is PlanetScale still worth it without a free tier?

For hobby projects, probably not, Neon and Turso both offer generous free tiers. For funded startups and enterprises that need Vitess-powered horizontal sharding or zero-downtime deploy requests, PlanetScale's pricing is justified. The $5/mo Postgres entry point is competitive, though not free.

What is the best serverless database for Next.js?

Neon, for most developers. It has the deepest Vercel integration (branch per preview deployment), works with all Postgres ORMs, and starts free. Turso is the pick if you specifically need global edge reads. All three have drivers that work in Vercel Edge Functions.

How bad are Neon cold starts in production?

Expect 400-750ms on the first query when compute wakes from zero. Subsequent queries are fast (single-digit ms). For always-responsive apps, set minimum compute to 0.25 CU (roughly $7/mo on the Launch plan) to keep the instance warm and eliminate cold starts entirely.

Can PlanetScale use PostgreSQL now?

Yes, since September 2025. PlanetScale launched PostgreSQL support as GA, with single-node databases starting at $5/mo. It's production-ready with hundreds of companies running on it. However, horizontal sharding for Postgres is still in development, for that, you'll need their Vitess/MySQL offering.

Is Turso good for production apps?

Yes, with caveats. Turso excels at read-heavy workloads and multi-tenant architectures. Write concurrency has improved significantly. It's best suited for apps with high read-to-write ratios and global distribution requirements. For write-heavy transactional workloads, Neon or PlanetScale are better fits.

What happened to PlanetScale's free tier?

PlanetScale removed its Hobby (free) tier in April 2024. New Hobby databases were blocked March 6, 2024, and all existing ones were retired April 8, 2024. The cheapest entry point is now $5/mo for a Postgres single-node database. This drove many solo developers to migrate to Neon or Turso.

How does the Databricks acquisition affect Neon?

Databricks acquired Neon for ~$1B in May 2025. Since then, Neon has cut storage costs 80%, invested in AI agent workflows, and gained enterprise credibility. Pricing has gotten cheaper, not more expensive. The acquisition signals long-term stability, Databricks is profitable and committed to Neon as its Postgres layer.

Does Turso still support scale-to-zero?

Turso deprecated scale-to-zero for new users in early 2025. Existing users on legacy plans keep it, but new signups get always-on instances. This eliminates cold starts but removes the "pay nothing when idle" advantage. Edge replicas were also discontinued for new users as part of the platform consolidation.

Which serverless database is cheapest for a side project?

Neon and Turso both offer free tiers that handle most side projects. Neon gives you 0.5 GB storage and 100 compute-hours. Turso gives you 5 GB storage and 500M row reads. PlanetScale has no free tier, the minimum is $5/mo. For a typical side project with light traffic, either free tier is more than enough.

Final Verdict

For most developers in 2026, Neon is the best serverless database to start with. It gives you the full Postgres ecosystem, a free tier that actually works for real projects, instant branching for CI/CD, and pricing that scales with usage. The Databricks backing adds enterprise stability without enterprise lock-in.

PlanetScale earns its place when you need horizontal MySQL sharding or your team is already invested in the MySQL ecosystem. Turso is the right pick when edge latency is a measurable requirement, not just a nice-to-have.

Assess your data model, your scaling trajectory, and where your users are. Then pick one and start building, all three are production-ready, and the Postgres/MySQL/SQLite ecosystems mean you're never truly locked in.

Sources

• Neon Architecture Overview
• Neon Pricing
• PlanetScale Pricing
• PlanetScale for Postgres Is Now GA
• Turso Pricing
• Turso libSQL Documentation
• Databricks Agrees to Acquire Neon
• Upcoming Changes to the Turso Platform
• PlanetScale Deprecating the Hobby Plan
• Serverless Database Latency Benchmarks, Pilcrow (2023)
• Drizzle ORM, Connect Turso