Three things broke the serverless database conversation open in the last twelve months, and if you picked your stack before any of them, you should probably look again.
Databricks bought Neon in May 2025 for around a billion dollars, then in late 2025 announced storage pricing dropping from $1.75 to $0.35 per GB-month and the free-tier compute allowance doubling. PlanetScale, which spent five years being the MySQL-and-only-MySQL Vitess shop, shipped Postgres in private preview in July 2025 and pushed it to GA on September 22. And Turso — the libSQL-flavored darling of the edge crowd — deprecated scale-to-zero for new accounts in January 2025 and pivoted toward always-on instances and embedded replicas.
Pick the wrong serverless Postgres in 2026 and the bill you signed up for at 10K rows is not the bill you’ll get at 50GB. I’ve been moving production workloads between three of these vendors in the last eighteen months, and the differences are sharper than the marketing makes them look.
What “serverless database” actually means in 2026
A serverless database in 2026 is doing four things: separating storage from compute so you pay for them independently, scaling compute up and down (or to zero) without you provisioning instances, exposing a branching workflow that mirrors how you branch code, and billing on usage instead of fixed-size boxes.
Every vendor below claims some version of this. Not all of them deliver all four. Turso, notably, just removed the scale-to-zero piece. PlanetScale never had it on the original MySQL side. Neon is the most aggressive on every axis, which is partly why Databricks paid a billion dollars for it.
Neon: the Postgres pioneer, now an enterprise checkbox
Neon’s whole architecture — compute pods that boot in under a second, storage in S3-backed Pageservers, scale-to-zero on idle — was the thing that woke up the category. Branching is the killer feature: every PR gets its own database, you run migrations against it, and you throw it away when you merge. That workflow alone is worth the switching cost for most teams.
The Databricks acquisition is the awkward part. On paper, Neon is still indie-friendly: the post-acquisition pricing actually got cheaper, the free tier got bigger, and the OSS roadmap kept moving. The free plan now gives you 0.5GB storage and 100 compute-hours per month, which is more than enough to host a side project. The Launch plan starts at $5/month with compute at $0.14 per CU-hour, and storage at $0.35/GB-month on paid plans.
But Databricks didn’t pay a billion dollars for free tiers. They paid for Neon to become the OLTP layer that feeds the Lakehouse, and the long-term roadmap pressure on Neon is “be the database every Databricks customer also uses.” That’s not bad for you as a buyer — the enterprise muscle behind it means it isn’t going anywhere — but if you picked Neon because it felt like the scrappy outsider, that vibe is gone.
Where Neon still wins: anywhere you want branching to be the primary workflow, anywhere you want serious scale-to-zero (cold starts are typically 500ms-1s on Free, faster on paid), and anywhere your team thinks in pure Postgres.
Where it loses: if you have a regulatory reason to avoid US-cloud-on-cloud arrangements (Databricks runs on AWS, Neon now inherits that posture), or if your team has a strong “no acquired-by-big-co databases” stance from past burns.
PlanetScale: the Vitess shop finally speaks Postgres
PlanetScale’s pitch for years was “Vitess for everyone, you don’t have to be YouTube to shard MySQL.” Then they killed the free tier in 2024, watched a wave of indie users leave for Neon, and quietly spent a year building Postgres support. It went GA in September 2025.
The Postgres tier on PlanetScale is a different product than the MySQL one in important ways. There’s no Vitess sharding for Postgres yet — what you get is single-node Postgres with PlanetScale’s deletion-protection-by-default, safe migrations, and the deploy-request workflow ported over. The entry point is $5/month per single-node database, and the Metal tier (NVMe-backed, dedicated CPU) starts at $50/month for production.
This is a real product, not a rebadge. The branching story (deploy requests, schema change reviews, automatic safety checks) is more mature than anything else in the category — five years of MySQL shipping went into it. If you’ve ever lost a Friday afternoon to a Postgres migration that locked a table for forty minutes, PlanetScale’s deploy-request flow is genuinely worth the price tag.
The catch: no scale-to-zero. PlanetScale was always allergic to that pattern — they argued (correctly, in some ways) that cold starts are a footgun for production traffic. So if your workload has long idle periods and you wanted to pay nothing during them, this isn’t your tool. The $5 floor is real; that’s the minimum you pay every month regardless of usage.
Worth checking: PlanetScale started charging $0.01/GB for private-connection ingress and egress on Postgres as of February 2026. If you’re routing a lot of traffic through a private VPC link, model that out before you commit.
Turso: SQLite at the edge, minus the original pitch
Turso is the awkward one to write about, because the version that exists in May 2026 is not the version most people remember. The original pitch — libSQL, scale-to-zero per-tenant SQLite databases at the edge, pay-as-you-go — was distinctive. Then in January 2025 they removed scale-to-zero for new signups, consolidated to AWS-only infrastructure, and discontinued edge replicas for new accounts.
What’s left is still interesting, but the value prop narrowed. Always-on libSQL instances, plus embedded replicas (now positioned as legacy in favor of Turso Sync) that let you read from a local SQLite file on the server and push writes back to the origin. For local-first apps, database-per-user multi-tenancy, or workloads where every read needs to be a microsecond instead of a millisecond, this is unmatched.
For “I want a general-purpose serverless database for my SaaS,” it’s a harder sell now. SQLite means no Postgres extensions, no PostGIS, no pgvector, no row-level security in the Postgres sense. Schema changes work differently. The ecosystem tooling — Prisma, Drizzle, etc. — supports it but treats it as a second-class citizen.
If you’re building a multi-tenant B2B app where each customer needs an isolated database (Turso’s database-per-tenant pricing math actually pencils out cheaply at high tenant counts), this is still the right tool. For most other use cases, the 2026 version of Turso is harder to justify than the 2024 version was.
Xata: the database-as-API that’s still finding its lane
Xata gives you Postgres underneath, but the surface area is a JSON-over-HTTPS API with branches, search, file attachments, and vectors baked in. It’s a lovely developer experience if you want the database to feel like an SDK and you don’t want to think about connection pooling.
In practice, I find Xata wins for two cases: small content-heavy apps where the search and file features save you from bolting on Algolia and S3 separately, and migration-from-Airtable type workflows where the spreadsheet-style UI is genuinely useful for non-engineers.
What it loses on: raw Postgres power-user features, predictable cost at scale (the API-call-based billing model can surprise you), and the broader Postgres ecosystem. If you ever want to drop down to psql and run an analytical query, you can, but it’s not the default experience and it’s not what the platform was built for.
Xata is also the one platform where the buyer needs to genuinely commit to the model. You’re not getting a vanilla Postgres instance with extras; you’re getting an API-first product that happens to run on Postgres.
Supabase Postgres: the BaaS context matters more than the database
Supabase’s bare Postgres tier is fine — it’s a normal Postgres with PgBouncer in front, point-in-time recovery on paid plans, read replicas, and the new Branching API that finally landed in late 2025. As a database alone, it’s competitive but not dominant.
The reason teams pick Supabase isn’t the database. It’s the BaaS stack around it: PostgREST giving you an auto-generated REST API, real-time subscriptions via Postgres logical replication, auth that integrates with row-level security, storage, edge functions. If you want one product that does eight things and you’re willing to accept that none of them is best-in-class, this is the play.
I’ve seen teams pick Supabase for the database alone and then six months later realize they’re using auth, storage, and edge functions too because the integration is too convenient to walk away from. That’s lock-in, but it’s the productive kind.
Where Supabase loses against Neon as a pure database: no scale-to-zero on the bundled Postgres, slower cold starts when projects go idle on the free tier (more like 1-3 seconds vs Neon’s sub-second), less aggressive separation of storage and compute pricing.
Honorable mentions you’ll see in the same searches
Cloudflare D1 is SQLite-on-Workers with a generous free tier — good for very small apps and Workers-native projects, not yet ready for general-purpose SaaS workloads. CockroachDB Serverless does multi-region SQL with strong consistency; the pricing is opaque enough that I won’t quote it, but for genuinely global apps that can’t tolerate regional reads, it’s the answer. Nile does per-tenant Postgres if Turso’s database-per-user pattern appeals but you need Postgres semantics. Tembo and TigerData (formerly Timescale) sit on the “specialized Postgres stack” axis — useful if you have a specific workload (timeseries, vector, etc.) but overkill as a general-purpose pick.
Branching: who actually unblocks preview environments
This is the feature that separates the 2026 generation from the 2018 generation. Branching means every PR gets a database instance, and your preview environment talks to it instead of a shared staging DB that everyone is stomping on.
Neon has the best branching story by a clear margin. Database-per-PR is a one-line GitHub Action, the branch creation is sub-second, and the data branches are copy-on-write so storage cost is negligible until you write a lot.
PlanetScale’s deploy-request model is more opinionated — branches are heavier and tied to schema-change workflows specifically. It’s better if your branching is mostly “I’m proposing a schema change and want a safe way to land it” and worse if your branching is “I just want a fresh DB for every PR.”
Supabase Branching 2.0 caught up enough to be usable, but it’s still slower (10-30 seconds to provision a branch in my testing) and the integration with Vercel preview deployments needs more glue than Neon’s.
Xata’s branch UI is the prettiest and the most accessible to non-engineers, which sometimes matters and sometimes doesn’t.
Turso doesn’t really do branching in the same sense — you can clone a database but the workflow isn’t built around it.
Pricing math at 1GB / 50GB / 500GB
Storage-heavy is where these vendors diverge sharply. At 1GB of data and modest compute, almost everyone is free or near-free. The interesting numbers are at 50GB and 500GB.
At 50GB with steady moderate traffic, Neon lands around $30-50/month on the Launch plan, PlanetScale single-node at this size is more like $40-60/month, Supabase’s Pro tier covers most of this for $25/month flat (plus compute), and Xata’s API-call billing makes it hard to predict but typically $30-80/month for this size.
At 500GB, the equation changes again. Neon’s per-GB storage is now $0.35/GB-month, so storage alone is $175/month plus compute. PlanetScale Metal at this size is in the $200-300/month range. Supabase requires Team or Enterprise pricing at this point. RDS at the same size is around $80-120/month for storage if you’re willing to manage the instance yourself — which is the migration question every team eventually faces.
The honest answer: serverless Postgres makes financial sense up to about 200GB of data. Past that, the math gets close to vanilla RDS, and you’re paying for the developer experience and the branching workflow rather than the storage itself. Whether that’s worth it depends on how often your team ships database changes.
My picks by use case
Indie SaaS MVP with React/Next.js stack: Neon, no contest. Branching changes how you ship, the free tier is generous, and the Vercel integration is one click.
B2B multi-tenant where each customer needs isolation: Turso’s database-per-tenant model is still the right answer, assuming you can live without Postgres extensions.
Mid-stage company moving off RDS, mostly to get safer migrations: PlanetScale. The deploy-request workflow is the reason to switch; the rest is table stakes.
Regulated EU fintech: Supabase with EU region pinning, or self-hosted Postgres on a managed provider. The acquisition lineage of Neon and PlanetScale (Databricks, large VC backing) is going to come up in your data-protection review.
AI-agent persistence layer: Neon, because the branching model maps cleanly to “every agent run gets its own database state.” This is the angle Databricks paid for.
Already-on-Supabase shop using auth + storage + edge functions: stay on Supabase. The lock-in is real but the productivity is also real.
What I’d actually try first
If you’ve been thinking about replatforming and reading this didn’t push you in a clear direction, do this: spin up a Neon free-tier project this afternoon, point your preview environment at it, and let your team’s PR workflow run against it for two weeks. That’s the cheapest way to learn whether the branching workflow changes how you ship — and if it does, the rest of the comparison stops mattering very much.
Sources: