NeonvsPlanetScale

Neon is full Postgres 16/17 with extensions: pgvector for embeddings, PostGIS for geospatial, pg_partman for partitioning, plv8, citext, etc. Anything you can do on a self-hosted Postgres works here. The protocol is standard, so any Postgres client (Prisma, Drizzle, raw pg) connects natively.

PlanetScale is MySQL 8 on Vitess. Most MySQL features are available, but with Vitess constraints: no foreign keys (enforced application-side), no cross-shard transactions, certain JOINs require care to stay performant. The Vitess query rewriting handles a lot of this transparently, but it's not 100% transparent.

Neon's branching is copy-on-write at the storage layer — creating a branch is essentially free (no data copy, just metadata) and takes seconds. You branch a database, run a destructive migration in the branch to test it, then either merge back or discard. Per-PR database branches are a real workflow at companies using Neon.

PlanetScale pioneered database branching but deprecated it in 2024. As of May 2026 they're rebuilding it (in beta) but the workflow is currently 'just don't do that.' Most teams that picked PlanetScale specifically for branching have either migrated away or are working around the gap.

Neon uses standard Postgres migration tools (Prisma migrate, Drizzle Kit, Atlas, raw SQL). For destructive migrations, the recommended pattern is: branch the database, run the migration on the branch, verify, merge. The platform doesn't add migration tooling — you bring your own.

PlanetScale's 'deploy requests' are the headline feature: you write a schema change, open a deploy request (like a PR), the platform validates it, runs it as a non-blocking online schema change, and rolls back if anything goes wrong. Zero-downtime DDL is genuinely solved here. For high-write schemas, this matters.

Neon supports foreign keys, check constraints, unique constraints, partial indexes, and every other Postgres data-integrity feature. ON DELETE CASCADE works. Composite primary keys work. The relational model is intact.

PlanetScale doesn't support foreign keys (Vitess limitation). Referential integrity is enforced at the application layer — your ORM or business logic checks that user_id in the orders table refers to a real user. Cascade deletes are application-level cleanup, not database-level.

Neon scales vertically — bigger compute, bigger storage, read replicas. The largest Neon instance handles workloads in the high-hundreds-of-GB range and tens of thousands of writes/sec. Beyond that, you'd partition the application layer (one Neon per tenant) or move to self-hosted Postgres with Citus.

PlanetScale on Vitess scales horizontally via sharding. Adding shards is a workflow, not a project — the platform handles resharding, query routing, and cross-shard joins where possible. Companies running multi-TB workloads (Cash App, GitHub, Slack at points) have used Vitess.

Neon ships pgbouncer-based pooling. The pooler URL is what you use from serverless functions; the direct URL bypasses the pool for long-running connections. Documentation is clear; failures from using the wrong URL show up early in development.

PlanetScale handles serverless connection patterns natively — there's effectively one URL, and the platform manages connection multiplexing transparently. You don't think about pooled vs direct; the system does it for you.

Neon prices on compute-hours (you pay when the database is awake) plus storage (you pay for what you store). Free tier suspends inactive databases. Launch ($19), Scale ($69), and Business tiers add features like multi-region, longer history, dedicated compute. The bill scales with actual usage.

PlanetScale prices by tier — Hobby ($39), Scaler ($99), Scaler Pro, Enterprise — with each tier including a fixed bundle of storage, IOPS, and rows-read. Overage adds linearly. The bill is more predictable but doesn't drop on idle.

Neon ━▶ PlanetScale: convert Postgres schema to MySQL (data types differ, foreign keys disappear, sequences become AUTO_INCREMENT), rewrite queries that use Postgres-specific syntax (ARRAY types, JSONB operators, RETURNING), redo any extensions. It's a real project.

PlanetScale ━▶ Neon: convert MySQL schema to Postgres (mostly mechanical), add foreign keys back where the application was emulating them, handle data types (TINYINT(1) → BOOLEAN, etc.). Slightly easier direction because you're gaining capabilities, not losing them.