PlanetScale launches Neki, a sharded Postgres database
PlanetScale has released Neki, a sharded version of Postgres, in a platform preview available now to anyone who opts in through their PlanetScale account. Neki lets a Postgres database scale across many machines while keeping real, unmodified Postgres running on every shard: applications connect to a Neki router over the standard Postgres wire protocol, so existing drivers, object-relational mappers and connection strings keep working without changes.
PlanetScale says Neki is built on eight years of running some of the largest sharded MySQL clusters in the world, serving thousands of production workloads at millions of queries per second for companies where even a few seconds of downtime is highly visible. PlanetScale released PlanetScale Postgres a year and a half before Neki and has since onboarded several thousand customers, some rivaling its largest MySQL customers in size. Its existing Metal offering bought some of those customers more time, but PlanetScale says it kept watching teams hit the ceiling of a single machine and had no good option to offer them once they got there; Neki is its answer.
PlanetScale frames the existing paths to scaling Postgres as each demanding a tradeoff. Moving to a bigger instance eventually runs out of machines big enough, and problems such as tables too large to vacuum or index without hurting live traffic, backups taking hours, connection limits, maintenance windows for schema changes and transaction ID wraparound do not scale away just by adding cores and IOPS. Application-level sharding pushes routing logic into a team's own code. Distributed databases that call themselves Postgres-"compatible," PlanetScale argues, hide the shard key from users, remove their extensions and add complexity and latency that becomes hard to handle and debug. Neki's stated principle is to stick to real Postgres rather than working around it, faking it or turning away from it.
Neki's architecture has four parts, PlanetScale says. Neki routers speak the Postgres wire protocol and carry their own query parser and a distributed query planner: they parse an incoming query, decide which shards need to run it, dispatch the work and combine the results into a single stream, and can scale both vertically and horizontally so no single router becomes a bottleneck. Under sharding and shard groups, every shard is a full, unmodified Postgres cluster with one primary and at least two replicas spread across three availability zones, and shards are organized into groups, each with its own configuration profile for instance size, replica count, storage, Postgres parameters and extensions, so different tables or workloads can be sized separately. For connection pooling, sidecars run alongside every Postgres instance, and because Neki controls both the router side and the Postgres side of a connection, it can size pools to what an instance can actually serve rather than estimating from outside, which PlanetScale says makes it meaningfully better than simply putting PgBouncer in front of a database. The control plane tracks the health of every node, runs planned switchovers and unplanned failovers, and coordinates the workflows that reshard data, apply schema changes and perform version upgrades. Tying these four together is a JSON configuration PlanetScale calls the data topology, which maps logical tables onto physical shards: it defines a shard index, the column Neki routes on and how that value is hashed, and shard groups, how many shards a set of tables spans and which ones, and routers cache and consult it on every query plan.
Everything that would normally need a maintenance window instead runs as a built-in online workflow through the same psql connection an application already uses: schema changes, version upgrades, planned and unplanned failovers, imports and resharding all provision new nodes, replicate data onto them, cut over traffic with a __neki metafunction, and retire the old nodes automatically. A database does not have to shard on day one: it can run on Neki unsharded, as a single primary with replicas, and still get the improved connection pooling, online DDL, zero-downtime upgrades and health monitoring, then reshard later as a workflow run against the cluster it already has. Neki also carries the PlanetScale features customers already use, including Insights, schema recommendations, branching and MCP support.
PlanetScale is explicit that this is a platform preview, not a production-ready release: the product is still changing, some of those changes will be breaking, and PlanetScale says production workloads should not run on Neki yet. To try it, a user signs into PlanetScale, opts into the platform preview and creates a Neki cluster, with documentation covering the architecture and how to shard. Anyone running a large Postgres cluster who wants to evaluate Neki can contact PlanetScale directly for a private demo built around their own schema and query patterns. The announcement gives no pricing, no supported cloud-provider or region list and no general-availability date, and it is written throughout in PlanetScale's own corporate voice rather than credited to a named engineer or executive.
Key facts
- PlanetScale has launched Neki, a sharded Postgres database now available in a platform preview, built on eight years of running large sharded MySQL clusters and a year and a half of running PlanetScale Postgres.
- Applications connect to a Neki router over the standard Postgres wire protocol, so existing drivers, ORMs and connection strings keep working unchanged.
- Each Neki shard is a full, unmodified Postgres cluster with one primary and at least two replicas spread across three availability zones.
- Schema changes, version upgrades, failovers, imports and resharding all run as built-in online workflows, and a database can start unsharded and reshard later against the cluster it already has.
- PlanetScale says the platform preview is still changing, some changes will be breaking, and production workloads should not run on Neki yet.
Why it matters
Sharding a database usually means giving something up: routing logic pushed into an application's own code, or a Postgres-"compatible" distributed database that drops extensions and adds latency in exchange for hiding the complexity. Neki's pitch is that a team does not have to choose, because every shard stays real, unmodified Postgres reachable over the standard wire protocol, so existing drivers, ORMs and tooling keep working unchanged. That claim carries more weight coming from PlanetScale specifically: the company says it is drawing on eight years of running some of the largest sharded MySQL clusters in the world and a year and a half of operating PlanetScale Postgres, during which it watched customers repeatedly hit the ceiling of a single machine with no good option to offer them. Neki is PlanetScale's attempt to close that gap rather than a new idea about how to shard a database.
Who it affects
The direct audience is teams whose Postgres database is approaching or has passed what one machine can handle: symptoms PlanetScale names include tables too large to vacuum or index without hurting live traffic, backups that take hours, connection limits, maintenance windows for schema changes and transaction ID wraparound. PlanetScale says it has already onboarded several thousand customers since launching PlanetScale Postgres, some rivaling the size of its largest MySQL customers, and frames those as the people Neki is for. Teams not yet at that scale are not forced into anything: Neki can run unsharded, as a single primary with replicas, so adopting it early does not mean sharding immediately. Teams evaluating rival distributed-Postgres products are the implicit second audience, since PlanetScale's pitch is framed as a direct alternative to that category, though it does not name which specific competitors it means.
How to use it
Trying Neki means signing into a PlanetScale account, opting into the platform preview and creating a Neki cluster; the application side needs no rewrite, since it connects through the existing driver, ORM and connection string via a Neki router. Sharding is configured through a JSON data topology that sets a shard key and groups tables into shard groups, each with its own instance size, replica count, storage, Postgres parameters and extensions, so different workloads can be sized independently. Teams not ready to shard can adopt Neki unsharded first and still gain its connection pooling, online DDL, zero-downtime upgrades and health monitoring, then reshard later as an online workflow against the cluster they already have, without a maintenance window. Existing PlanetScale features, Insights, schema recommendations, branching and MCP, carry over. Anyone running a large Postgres cluster can also ask PlanetScale directly for a private demo built around their own schema and query patterns. No price is stated anywhere in the announcement.
How solid is it
Neki ships as a platform preview, PlanetScale's own term for a stage explicitly not meant for production workloads, because the product is still changing and some of the coming changes will be breaking. Every architectural claim here, the router's query planner, shards built from real Postgres with one primary and at least two replicas across three availability zones, per-instance connection-pooling sidecars, and a control plane that runs failovers and coordinates resharding, is PlanetScale's own description of a system it built, not independently verified in the source. PlanetScale grounds the design in eight years of large-scale sharded MySQL operation and a year and a half of running PlanetScale Postgres with several thousand customers onboarded, but the announcement gives no adoption, performance or reliability numbers for Neki itself, and credits no individual engineer or executive; it speaks throughout as PlanetScale's institutional "we".
Risks and caveats
PlanetScale itself warns against running production workloads on Neki during the platform preview and says breaking changes are still coming, so anything built on it now should expect rework. The announcement gives no calendar date for the release or for a general-availability target, no pricing, and no list of supported cloud providers or regions. It criticizes Postgres-"compatible" distributed databases for hiding the shard key, dropping extensions and adding complexity and latency, but does not name which competing products it means, so that comparison cannot be checked against a specific alternative. And the scale figures in the announcement, eight years of MySQL-sharding experience, thousands of production workloads, millions of queries per second, several thousand customers, describe PlanetScale's existing business in general rather than measured results for Neki specifically.