PlanetScale's Neki: the Vitess playbook, now aimed at Postgres

What happened

PlanetScale, the company that spent the last decade turning Vitess — YouTube's MySQL sharding layer — into a managed database business, has announced Neki, a horizontal sharding system for Postgres. In their words, Neki is being built to give Postgres the same properties Vitess gives MySQL: transparent sharding across many primaries, online resharding without downtime, connection pooling that survives long-tail traffic, and a query layer that speaks the native wire protocol so applications don't have to know they're talking to a sharded fleet.

This is PlanetScale taking the exact architectural ideas that made Vitess famous inside Google and porting them, deliberately, to the database that most new companies in 2026 actually choose on day one. The blog post frames Neki as the answer to a specific pain: Postgres is the default now, but Postgres-at-scale is still a project. Teams either vertically scale a monster primary until it stops being funny, adopt a NewSQL system like CockroachDB or Yugabyte and rewrite their assumptions about latency and transactions, or bolt on Citus and pray their access patterns cooperate. Neki's pitch is that none of those tradeoffs should be necessary — you should be able to keep vanilla Postgres and have the sharding layer be someone else's problem.

The launch is early. There's no GA date, no pricing, no benchmarks against Citus or Aurora Limitless yet. What there is: a public commitment, a technical direction, and — crucially — a team that has already built the thing they're now promising to build again, in a different SQL dialect.

Why it matters

The Postgres-at-scale market has been strangely under-served for how loudly everyone has been shouting about it. Citus, now owned by Microsoft, is the obvious incumbent — but Citus is opinionated about distribution keys and has never really escaped the Azure orbit. Yugabyte and CockroachDB are Postgres-compatible rather than Postgres, and both have quietly walked back some compatibility claims when customers ran into edge cases with extensions, sequences, or transaction semantics. Neon and Xata solved the *storage* scaling problem elegantly but leave the write path a single primary. AWS's Aurora DSQL and Aurora Limitless are the most credible enterprise answer, but they're AWS-only and, in DSQL's case, are a rebuilt engine rather than Postgres itself.

Neki's bet is that developers don't want a Postgres-like database — they want Postgres, unmodified, with a smarter proxy in front of it. That is a fundamentally different posture than everything else in the space. Vitess made the same bet for MySQL and won it: the reason YouTube, Slack, Square, GitHub, and eventually PlanetScale's customer base stayed on MySQL instead of migrating to a NewSQL system is precisely because Vitess didn't ask them to give up MySQL. It asked them to put a router in front of it.

Whether that bet transfers to Postgres is not a foregone conclusion. Postgres has a richer type system, extensions that touch internals in ways MySQL plugins don't, and a much more diverse ecosystem of client libraries with idiosyncratic wire-protocol behavior. Sharding logical replication, foreign keys across shards, and transactions that span shards are the well-known hard problems — and "solved on MySQL" doesn't automatically mean "easy on Postgres." The Citus team has been chipping away at these problems for a decade. Whatever PlanetScale ships, it will be measured against that decade of prior art on day one.

The other reason this matters is who's building it. PlanetScale spent 2023 and 2024 in a strange middle place: killed the free tier, watched a chunk of hobbyist mindshare defect to Neon and Supabase, then leaned harder into the enterprise Vitess business that was always the actual company. Neki reads as the natural next move — the same operational DNA, applied to the database where the enterprise customers actually are now. If you're a CTO who picked Postgres in 2022 and is now watching your primary sweat, the vendor calling you next quarter is going to be PlanetScale.

What this means for your stack

For most teams reading this, the honest answer is: not yet, but soon. Neki isn't GA. You cannot put it in front of production Postgres this week. What you *can* do is take the announcement as a signal about the shape of the Postgres-at-scale market over the next 18 months, and plan accordingly.

If you're currently on a single Postgres primary and starting to feel the ceiling — write throughput, connection counts, vacuum pain, replication lag — the correct move is still to fix the immediate pain with the tools that exist today (PgBouncer, read replicas, partitioning), while explicitly avoiding architectural choices that would make future sharding harder. That means: no cross-tenant foreign keys you can't live without, no assumptions that a single transaction can touch arbitrary rows, tenant IDs (or whatever your shard key candidate is) threaded through your data model early. This is good hygiene regardless of whether Neki, Citus, or Aurora Limitless ends up being the layer you adopt.

If you're evaluating a NewSQL migration right now — CockroachDB, Yugabyte, TiDB, Spanner — Neki is a reason to pause and ask whether the pain you're solving is really "my database engine is wrong" or "my database is a single box." Those are different problems and they have different answers. NewSQL migrations are expensive, often multi-quarter projects that touch every service. A sharding proxy in front of unmodified Postgres, if it works, is a much smaller lift.

And if you're on Citus today: nothing changes immediately, but the competitive pressure on Microsoft to invest in Citus outside the Azure moat just went up. That is probably good for you.

Looking ahead

The interesting question isn't whether Neki will ship — PlanetScale has the team and the muscle memory to ship it. The interesting question is whether the Vitess playbook actually generalizes. Vitess worked because MySQL's replication model, its relatively thin extension surface, and YouTube's specific access patterns lined up with what a smart proxy could paper over. Postgres is a different animal. If Neki ends up needing a custom Postgres fork to make sharding work cleanly, the whole "it's still just Postgres" pitch weakens. If it doesn't, PlanetScale has just credibly threatened every managed-Postgres vendor in the market. Watch the first benchmark, and watch how it handles extensions. Those two data points will tell you which version of this story you're looking at.