September 2026 Summaries

Neki, released in platform preview, was benchmarked at 118.5 million queries per second across 512 PostgreSQL-backed shards containing 1.22 PiB of data, substantially exceeding an initial goal of 1 million QPS. The test used isolated, single-shard primary-key point reads that fetched one row per query, without writes, joins, cross-shard queries, replicas, or failover testing. Results showed near-linear scaling from five shards at roughly 1 million QPS to 50 shards at 9.9 million and 512 shards at 118.5 million, with each shard reaching about 231,000 QPS. During a 16-minute sustained run, the system recorded p99 latency of 6.06 milliseconds at routers and 13.95 milliseconds at clients, approximately 67 errors per second, 15.8 million read IOPS, and more than 2 Tbps of network traffic.

PlanetScale has introduced Neki, a platform-preview service for sharded PostgreSQL designed from its experience operating large sharded MySQL deployments and addressing the limits of scaling a single Postgres machine. Neki distributes PostgreSQL databases across multiple machines while retaining standard Postgres clusters, SQL behavior, extensions, drivers, ORMs, and wire-protocol compatibility. Applications connect through scalable Neki routers that parse, plan, route, and combine distributed queries, while shard groups allow tables and workloads to be independently distributed and configured. Each shard includes a primary and at least two replicas across three availability zones, with sidecars providing managed connection pooling and a control plane coordinating monitoring, failovers, schema changes, upgrades, imports, and resharding. Database topology is configured through JSON definitions of shard keys, hashing, and shard groups, and online workflows aim to avoid maintenance windows. Neki can initially operate as an unsharded primary-and-replica cluster before customers reshard as demand grows, and it includes PlanetScale features such as Insights, schema recommendations, branching, and MCP. The company states that Neki remains under active development during the preview and should not yet be used for production workloads.

Neki presents a sharded PostgreSQL architecture designed to make databases distributed across many servers appear to applications as a single Postgres instance, while handling authentication, wire-protocol compatibility, SQL parsing, distributed planning, failures, and connection pooling. Using a customer-and-orders join as an example, it traces how a router implements PostgreSQL SCRAM authentication and both simple and extended query protocols, parses SQL into an abstract syntax tree, consults cached schema and shard-topology metadata, and creates a distributed execution plan. When customers and orders are sharded independently by their IDs, related rows may reside on different shards, requiring scatter-gather requests and a router-side hash join that can spill to disk if memory is insufficient; individual shards still use PostgreSQL’s native planner to execute their assigned subqueries. Requests travel through sidecars that pool reusable Postgres connections and restore the correct session settings and role, while results are streamed back and, where possible, forwarded using their existing encoded values to reduce processing. For distributed aggregates such as AVG, the router rewrites calculations into shard-local sums and counts before combining them centrally. The discussion concludes that choosing compatible shard keys, such as sharding orders by customer_id alongside customers by id, colocates related data so PostgreSQL can perform joins locally, reducing router work and network requests.

Neki is a Postgres-compatible routing layer for sharded databases that determines which shards should execute a query and coordinates results before each selected Postgres instance creates its own execution plan. A stateless fleet of routers sits between applications and database shards, handling client connections, session state, SQL parsing, query planning, and distributed processing without requiring a separate Postgres backend process per client connection or an additional PgBouncer layer. Routers send planned work over gRPC to sidecars beside each Postgres instance, which use pooled connections to forward requests and stream responses. Queries containing a shard key, such as a user ID, can be routed to one shard and use reusable parameterized plans, while queries without a shard-key predicate are scattered across all relevant shards and then gathered, limited, or otherwise combined by router operators. Neki’s EXPLAIN options reveal both its distributed routing plan and representative Postgres execution plans, helping users inspect routing choices, remote work, and runtime behavior. By independently scaling routers for connection handling and distributed query processing and shards for data storage and database capacity, Neki is designed to grow beyond the limits of a single Postgres instance.