Serverless PostgreSQL: Neon vs Supabase vs PlanetScale

Three architectures, one problem

Good evening. Three guests have arrived, each claiming to solve the same problem. Allow me to make the introductions.

The "serverless database" label covers three fundamentally different approaches to the same problem: how to give developers a database that scales down to zero and up to production without managing infrastructure.

Neon separates PostgreSQL compute from storage. The compute suspends when idle, the storage layer persists independently. It is serverless at the database engine level — the PostgreSQL process itself starts and stops on demand.

Supabase runs managed PostgreSQL on dedicated instances with a rich platform layer built around it: authentication, real-time subscriptions, object storage, edge functions, and an auto-generated REST API. The PostgreSQL instance is always running. Supabase is not serverless at the database level, but it is serverless at the platform level.

PlanetScale runs Vitess, a MySQL-compatible horizontal scaling layer originally built at YouTube. It is not PostgreSQL at all. It appears in this comparison because developers evaluating a serverless database frequently consider all three services, and understanding the architectural differences helps clarify the decision.

This comparison explains the architecture behind each service, then compares connection handling, PostgreSQL compatibility, developer experience, and pricing. The goal is not to rank them — it is to make the trade-offs clear enough that the right choice for your particular situation becomes apparent.

Architecture deep dive

Neon — compute-storage separation

Neon's core innovation is worth understanding in detail. They replaced PostgreSQL's local storage with a custom distributed storage engine called Pageserver. Standard PostgreSQL assumes its data files live on a local disk. Neon breaks that assumption: compute instances (standard PostgreSQL processes) read and write pages over the network to the Pageserver, which handles durability, replication, and point-in-time recovery.

This separation enables Neon's defining features:

Auto-suspend. When no queries arrive within a configurable timeout (default: 5 minutes), the compute instance shuts down. The storage layer continues to persist the data. The next query triggers a cold start: Neon launches a new compute instance, connects it to the storage layer, and the query executes. Cold start latency is typically 500ms to 2 seconds.

Auto-scaling. Compute can scale up and down based on CPU and memory utilization within configured bounds. Scaling happens without connection interruption for most workloads.

Branching. This is where the architecture earns its keep. Neon can create instant copy-on-write database branches from any point in time. A branch is a full copy of the database at the moment of branching, but it consumes no additional storage until data diverges. Branching takes under a second regardless of database size. This is Neon's most distinctive feature and the one most difficult for competitors to replicate, because it is a property of the storage layer, not a feature bolted onto PostgreSQL.

Supabase — managed PostgreSQL with a platform

Supabase runs a standard PostgreSQL instance on dedicated infrastructure. The PostgreSQL process is always running. There is no auto-suspend. There is no scale-to-zero at the database level.

Supabase's value proposition is the platform built around PostgreSQL:

• PostgREST. An auto-generated REST API that maps directly to your PostgreSQL schema. Create a table, and the API endpoint exists immediately.
• Auth. User authentication and authorization built on PostgreSQL's Row Level Security (RLS).
• Realtime. WebSocket-based real-time subscriptions to database changes, built on PostgreSQL's logical replication.
• Edge Functions. Deno-based serverless functions deployed globally.
• Storage. S3-compatible object storage with PostgreSQL-backed metadata and access control.

The PostgreSQL instance itself is unmodified. Every extension, every feature, every PostgreSQL behavior works exactly as documented. The trade-off: you pay for the instance whether it is running queries or not.

Connection pooling is handled by Supavisor, a custom connection pooler Supabase built to replace PgBouncer.

PlanetScale — Vitess, not PostgreSQL

PlanetScale runs Vitess, a MySQL-compatible database clustering system originally built at YouTube. It is included in this comparison because developers frequently compare all three services, and the architectural differences deserve honest discussion rather than dismissal.

PlanetScale's strengths are genuine:

• Non-blocking DDL. Schema changes (ALTER TABLE) happen without locking the table. For tables with hundreds of millions of rows, this is significant.
• Horizontal sharding. Vitess distributes data across multiple MySQL instances transparently.
• Connection handling. The Vitess proxy layer handles connection multiplexing natively. No separate pooler to configure.

The trade-offs are also significant: foreign keys are disabled by default, stored procedures and triggers are unavailable, subquery support is limited, and the entire PostgreSQL extension ecosystem does not exist. For teams with PostgreSQL expertise, schemas, or extension dependencies, PlanetScale requires a fundamentally different approach.

Connection handling

Cold starts and connection establishment

If I may direct your attention to what is, in practice, one of the most consequential differences between these services.

Neon. When the compute is suspended, the first query triggers a cold start of 500ms to 2 seconds. Subsequent connections to a running compute have standard PostgreSQL latency (under 10ms). Neon also provides a serverless HTTP driver that eliminates TCP connection overhead entirely.

Supabase. No cold start. The PostgreSQL instance is always running. Connection establishment is standard PostgreSQL.

PlanetScale. No cold start. The Vitess proxy layer is always running and accepts connections quickly.

Connection pooling

Serverless platforms create a new database connection for every function invocation. Without connection pooling, a traffic spike can exhaust PostgreSQL's max_connections in seconds. This is the connection storm problem and all three services address it:

• Neon. Built-in PgBouncer-based pooler on the -pooler connection endpoint. Operates in transaction pooling mode. See the pooling guide and pooler comparison.
• Supabase. Supavisor, Supabase's custom-built pooler, supports both transaction and session mode.
• PlanetScale. The Vitess proxy handles connection multiplexing natively. No separate pooler to configure.

PostgreSQL compatibility and extensions

This section matters most — and I would encourage careful attention here — for teams with existing PostgreSQL expertise, schemas, or extension dependencies.

Extension support

Neon. Supports most popular extensions: pgvector, PostGIS, pg_stat_statements, pg_trgm, hstore, citext, uuid-ossp, and dozens more. Some extensions requiring shared_preload_libraries have restricted availability.

Supabase. Supports the widest extension ecosystem of the three. pg_cron, pgvector, PostGIS, pg_net, pgjwt, and 50+ others available out of the box.

PlanetScale. Not applicable. PlanetScale runs MySQL, not PostgreSQL. There is no pgvector, no PostGIS, no pg_stat_statements.

SQL compatibility

Neon and Supabase. Full PostgreSQL SQL compatibility. CTEs, window functions, LATERAL joins, JSONB, stored procedures, triggers, foreign keys, partial indexes, row-level security — everything PostgreSQL supports, both support.

PlanetScale. MySQL SQL with Vitess-imposed limitations. Foreign keys disabled by default. LISTEN/NOTIFY has no equivalent. JSONB does not exist. CTEs with write operations are not supported.

For teams migrating from PostgreSQL or building on PostgreSQL-specific features, PlanetScale requires rewriting queries, redesigning schemas, and finding alternative approaches. This is not a criticism — it is a different database serving a different ecosystem. The gap simply runs deeper than a feature table can convey.

Developer experience

Getting started

Neon. Database provisioned in under 10 seconds. Dashboard focused on the database: SQL editor, branching interface, compute and storage metrics. CLI (neonctl) and API available.

Supabase. Project provisioned in approximately 2 minutes (includes PostgreSQL, auth, API, realtime, storage). Extensive dashboard with SQL editor, table editor, auth configuration, and API documentation generated from your schema.

PlanetScale. Database provisioned quickly. Dashboard emphasizes the branch-based workflow. CLI-first experience with strong tooling for schema management.

Branching and preview environments

Neon. Instant copy-on-write branches from production data. Sub-second creation regardless of database size. Ideal for PR preview environments. This is Neon's strongest differentiator.

Supabase. No native database branching as of March 2026. Preview environments require creating separate projects or manual cloning. For teams that need per-PR database environments, this is a significant gap.

PlanetScale. Branch-based workflow built in, but focused on schema changes — the branch contains the schema diff, not a copy of the data. Conceptually different from Neon's data branches.

Pricing comparison

Free tiers

Neon. Generous free tier: 0.5 GB storage, 190 compute hours per month. Auto-suspend means idle databases consume zero compute hours.

Supabase. Free tier includes 500 MB database storage, 2 projects, 50,000 monthly active auth users, shared compute. The compute is always-on.

PlanetScale. Removed its free tier in early 2024. The lowest paid plan starts at $39/month.

Production pricing models

The three services bill on different dimensions, which makes direct price comparison misleading without specifying a workload.

Neon. Billed on compute time, storage, and data transfer. Auto-suspend means you only pay for compute when queries are running. The Pro plan starts at $19/month.

Supabase. Billed on instance size (fixed monthly cost), database storage, bandwidth, and platform feature usage. Predictable costs. The Pro plan starts at $25/month.

PlanetScale. Billed on rows read, rows written, and storage. A query that scans 100,000 rows bills for 100,000 row reads. The Scaler plan starts at $39/month.

The key distinction: Neon's cost scales with compute activity (idle equals nearly free). Supabase's cost is instance-based (idle equals the same cost as busy). PlanetScale's cost scales with row operations (cost proportional to query volume).

Cost for common scenarios

Side project (low traffic, frequently idle). Neon is the most cost-effective choice. Auto-suspend means zero cost during idle hours.

SaaS application (steady, predictable traffic). Supabase and Neon are comparable. Supabase's fixed-cost model is easier to budget.

Burst traffic (event-driven, unpredictable spikes). Neon's auto-scaling handles bursts. PlanetScale handles bursts natively but the per-row-read cost scales linearly with traffic.

When to choose each

Choose Neon when

• Scale-to-zero matters. Side projects, development databases, multi-tenant platforms with hundreds of databases.
• Branching is valuable for your workflow. PR preview environments, integration tests against realistic data, migration testing.
• You need PostgreSQL without platform lock-in. The connection string works with any PostgreSQL client. Migrating away means pointing at a different host.
• Cold starts of 500ms-2s are acceptable. API backends, background workers, and applications where occasional latency spikes are tolerable.

For Neon-specific optimization, see the Neon optimization guide.

Choose Supabase when

• You want a platform, not just a database. Auth, real-time, storage, edge functions, and an auto-generated REST API.
• Always-on availability is required. Cold starts are unacceptable for your use case.
• Maximum extension support matters. You depend on extensions beyond the most popular ones.
• You want a visual management experience. Table editor, SQL editor, auth management, real-time logs, and API docs.

For Supabase-specific optimization, see the Supabase optimization guide.

Choose PlanetScale when

• You are building on MySQL. Your team has MySQL expertise and existing MySQL schemas.
• Non-blocking schema changes are critical. Tables with hundreds of millions of rows where DDL locking would be disruptive.
• You need transparent horizontal sharding. Write volume exceeds what a single server can handle.
• PostgreSQL-specific features are not required. No pgvector, PostGIS, JSONB, LISTEN/NOTIFY, or foreign keys needed.

Honest counterpoint — what this comparison cannot tell you

I should be forthcoming about the limits of this comparison, because pretending it is comprehensive would be a disservice.

Performance benchmarks are omitted intentionally. Benchmark numbers vary with workload type, query pattern, data size, network topology, and time of day. All three services are fast enough for production workloads. The architecture differences — not raw query latency — are what differentiate them.

This comparison reflects March 2026. All three services iterate rapidly. The architectural differences are stable, but specific features and pricing are moving targets.

"Serverless" means different things. Neon's compute is serverless (scales to zero). Supabase's platform is serverless (edge functions, auto-generated API) but its database is not. PlanetScale's scaling is serverless (horizontal sharding is transparent). Choose based on which layer of "serverless" matters for your use case.

Comparing Neon and Supabase to PlanetScale is inherently uneven. PostgreSQL and MySQL are different databases with different strengths, ecosystems, and extension models. The comparison is included because developers make this decision, and the differences deserve honest treatment.

None of these services is the wrong choice made in good faith. Each solves a real problem for a real audience. The decision depends on your specific requirements — scale-to-zero needs, platform features, PostgreSQL compatibility, budget constraints, and team expertise. Choosing based on your requirements is better than choosing based on general rankings.

For the broader context of scaling PostgreSQL, including self-hosted options, see the scaling decision framework.