PlanetScale's Neki Brings Sharding to Real Postgres

PlanetScale has launched Neki in platform preview: sharded Postgres where every shard is an unmodified Postgres cluster. The pitch is narrow and specific — you keep real Postgres semantics, extensions, and SQL behavior, and you scale horizontally by adding shards rather than by buying a bigger box.

The company frames it as the answer to a problem it kept hitting with PlanetScale Postgres customers: teams run out of single-machine headroom, and the existing escape hatches all cost something. Application-level sharding pushes routing logic into your code. Postgres-compatible distributed databases hide the shard key, drop extension support, and add latency that is hard to debug. Neki's bet is that a router speaking the Postgres wire protocol lets you avoid both.

Architecture: four moving parts

Your application connects to a Neki router over the standard Postgres wire protocol using a single connection string. The router carries a full Postgres query parser and a distributed query planner: it parses the query, decides which shards should execute it, dispatches the work, and merges results into one stream. Routers scale vertically and horizontally, so the router tier itself isn't meant to be a fixed bottleneck.

Behind the router, shards are full Postgres clusters — one primary and at least two replicas spread across three availability zones. There is no custom storage engine. Shards are grouped into shard groups, which lets different tables or workloads live on separate shard sets, each with its own configuration profile covering instance size, replica count, storage, Postgres parameters, and extensions.

Connection pooling runs as sidecars next to every Postgres instance. This is the part PlanetScale claims is meaningfully better than parking PgBouncer in front of a database: because Neki owns both ends of the connection, it can size pools against what an instance can actually serve rather than estimating from outside the process.

The control plane tracks node health, runs planned switchovers and unplanned failovers, and coordinates the workflows for resharding, schema changes, and version upgrades. Tying it together is the data topology, a JSON config mapping logical tables onto physical shards. You define shard indexes — the column Neki routes on and how it hashes the value — plus shard groups controlling how many shards a table set spans. Routers cache the topology and consult it on every plan.

Online operations, and the unsharded on-ramp

Work that normally means a maintenance window runs as a built-in workflow: provisioning target nodes, catching them up via replication, switching traffic through a __neki metafunction, and retiring old nodes — all over the same psql connection your app uses. That model covers schema changes, version upgrades, failovers, imports, and resharding.

You don't have to shard on day one. Neki runs as a single primary with replicas, giving you the improved pooling, online DDL, zero-downtime upgrades, and health monitoring up front. Resharding later is a workflow against the cluster you already have. PlanetScale features like Insights, schema recommendations, branching, and MCP come along.

The preview caveat

This is a platform preview, and PlanetScale is explicit: don't run production workloads on it. The product is still changing, and some changes will be breaking. Feedback goes through support tickets or their Discord.