PlanetScale launches Neki, sharded Postgres built to reach hundreds of millions of QPS

What Neki is

PlanetScale has launched Neki, a sharded Postgres service that spreads one logical database across many machines while running unmodified PostgreSQL on every shard. According to the company's announcement post, it is built to reach hundreds of millions of queries per second and petabytes of data, and it is available now in platform preview.

The core pitch is that each shard is genuine Postgres: there is no custom storage engine, so extensions, SQL behaviour, and performance stay the way developers expect. Applications connect to a Neki router over the standard Postgres wire protocol, so existing drivers, ORMs, and connection strings keep working.

PlanetScale frames the product as an extension of its history. The company says it has spent eight years operating some of the largest sharded MySQL clusters in the world, and that since launching PlanetScale Postgres about a year and a half ago it has onboarded thousands of customers, some as large as its biggest MySQL users. Those teams repeatedly hit the limit of what a single machine could do, the post explains, and had no good next step.

How the architecture works

Neki has four main components plus a configuration layer.

Routers sit in front of the fleet. Each contains a full Postgres query parser and a distributed query planner: it parses a query, decides which shards should run it, sends the work out, and merges the results into a single stream. Routers scale vertically and horizontally so no single router becomes the bottleneck.

Every shard is a full Postgres cluster with one primary and at least two replicas across three availability zones. Shards are organised into shard groups, letting different tables or workloads run on separate hardware profiles, with instance size, replica count, storage, Postgres parameters, and extensions set per group.

Sidecars run alongside each Postgres instance and handle connection pooling. PlanetScale argues this beats putting PgBouncer in front of a database, because Neki controls both ends of each connection and can size pools to what an instance can actually serve rather than estimating from outside the process.

A control plane tracks node health, runs planned and unplanned failovers, and coordinates operational workflows. Tying it together is a JSON data topology that maps logical tables onto physical shards: shard indexes define which column Neki routes on and how values are hashed, and routers cache the topology and consult it for every query plan.

Online operations instead of maintenance windows

Everything that would normally be scheduled as a maintenance window runs as a built-in workflow: schema changes, Postgres version upgrades, failovers, imports, and resharding. Each workflow provisions new target nodes, catches them up with replication, switches traffic using a __neki metafunction, and retires the old nodes, all through the same connection an application already uses.

Cross-shard writes are coordinated so commits are atomic: either every shard applies a transaction or none do. Each shard keeps its own write-ahead log and logical replication path, so change data capture stays compatible with standard Postgres patterns. An existing database can be imported by copying data, replicating ongoing changes, verifying, and then cutting over while the source keeps serving traffic. Neki can also run unsharded as a single primary with replicas, so teams can adopt the pooling and online operations first and trigger resharding later as a workflow against the same cluster.

PlanetScale's existing features, including Insights, schema recommendations, branching, and MCP, carry over.

Platform preview caveats

The company is explicit that Neki is not production-ready yet. The post warns that the product is still changing and that some of those changes will be breaking, and it asks for feedback through support tickets or Discord. Access requires opting in through the PlanetScale dashboard.

Why it matters

The scaling problems Neki targets are familiar to anyone running a fast-growing Postgres deployment: tables too large to vacuum or index without hurting traffic, backups that take hours, connection limits, maintenance windows for schema changes, and transaction wraparound. Bigger instances only postpone the issue, and as PlanetScale notes, performance does not scale linearly as cores and IOPS are added.

The existing alternatives each demand a trade-off. Application-level sharding pushes routing into application code, while Postgres-compatible distributed databases tend to hide the shard key, drop extension support, and add latency that is difficult to debug. Neki's bet is that explicit shard keys, real Postgres on every node, and online operational workflows offer a third path, bringing PlanetScale's MySQL-era sharding experience into an increasingly contested distributed Postgres field. Until it exits preview, however, production adoption remains a wait-and-see question.