PlanetScale released Neki, sharded Postgres that keeps real Postgres on every shard, in platform preview

PlanetScale released Neki, a sharded Postgres product, in platform preview on 10 September 2026. The introduction post is signed by CEO Nick Van Wiggeren and lays out the shape of the system: an application connects to a Neki router over the standard Postgres wire protocol, the router parses the query, decides which shards should run it, and combines the results back into one stream. Every shard is a real Postgres cluster with one primary and at least two replicas across three availability zones, and there is no custom storage engine.

The company frames Neki as the answer to a problem it kept seeing in its Postgres customers. In the post, Van Wiggeren writes that PlanetScale onboarded "several thousands of customers on Postgres" after launching PlanetScale Postgres a year and a half ago, and that some rival the size of its largest MySQL accounts. Teams kept approaching the single-machine ceiling for Postgres, and moving to a bigger instance eventually runs out of room. Application-level sharding pushes routing into product code, and Postgres-compatible distributed databases "hide the shard key from you" and "take away your extensions", the post says.

Four moving parts

The Neki router speaks the Postgres wire protocol, so existing drivers, ORMs, and connection strings keep working with a single connection string. Each router carries a full Postgres query parser, a distributed query planner, and query buffering, and can scale vertically and horizontally.

Shards are grouped into shard groups, so different tables or workloads can live on different sets of shards. Each shard uses a configuration profile defining instance size, replica count, storage, Postgres parameters and extensions. Sidecars run alongside every Postgres instance for connection pooling, and because Neki controls both ends of the connection, it can size pools to what each instance can actually serve, rather than estimating like PgBouncer does from outside the process.

Sitting under it is a control plane that tracks node health, runs switchovers and failovers, and drives the workflows that reshard data, apply schema changes, and perform version upgrades. Tying it together is a JSON data topology that maps logical tables onto physical shards through shard indexes and shard groups. Routers cache the topology and consult it on every plan.

Sharding is a workflow, not a decision at day one

The post is explicit that a team does not have to start sharded. Neki runs as a single primary with replicas from the start, and when a cluster outgrows one machine, resharding is a workflow the team runs against the cluster it already has. Schema changes, version upgrades, failovers, imports and resharding all run as built-in fully online workflows, and traffic is switched with a __neki metafunction from the same psql connection the application already uses. Insights, schema recommendations, branching and MCP support are shared with PlanetScale Postgres.

Platform preview is a paid but not-yet-generally-available tier. There is no separate open-source component: the router, sidecars and control plane are proprietary, and the value of "real Postgres on every shard" is that extensions, SQL support and single-node performance behave the way upstream Postgres behaves. The Hacker News thread on the announcement drew 270 points overnight and a long back-and-forth about how the router handles cross-shard joins and whether the design is meaningfully different from Citus. The blog covers query planning and connection pooling in detail but does not benchmark it against Citus or Aurora Limitless.

For a team on Postgres eyeing a single-machine limit, the choice is now whether to keep vertically scaling, move to a Postgres-compatible distributed database, or take the piece that promises the same Postgres you already run.

Source

The PlanetScale post, Introducing Neki, and the Hacker News discussion.