The core challenge in operating a sharded database is deciding which shard(s) should execute a query. Each query passes through two plans.The Neki router builds the first plan using the data topology to decide which shard(s) receive the work and how results from multiple shards should be handled. Postgres then builds the plan you already know how to read, which decides how each selected shard executes its work.A fleet of routersOne of Postgres's fundamental scaling constraints is its process-per-connection architecture. Every direct connection requires a backend process on the Postgres instance it reaches. Those processes consume memory, and large process counts add scheduling overhead.This becomes a bottleneck for applications that want thousands of client connections.Neki changes this relationship by putting a fleet of routers between the application and Postgres. Routers handle client connections within their own process instead of requiring a separate Postgres backend process for each connection. On one side, the application connects with a single connection string. On the other is a database that can span anywhere from a single shard to thousands, each backed by a Postgres primary and its replicas.Neki routers are operationally stateless. They do not store durable application data, and their cached data topology, table definitions, and query plans can be rebuilt. This makes it easy to add, resize, or even remove routers as workloads change. If a router fails, the sessions connected to it are lost. Clients can reconnect to a different healthy router.This gives a Neki database two different scaling knobs. Shards scale data and the core database engine (Postgres). Routers scale distributed query processing and client connection handling.The router speaks PostgresTo an application, a Neki router provides one dedicated Postgres connection to one database. Existing drivers, frameworks, and tools connect normally.Behind that connection, the router may coordinate work over shared connections to many Postgres instances.Making this work requires more than speaking the Postgres protocol. With Neki, the router becomes the application's Postgres endpoint, removing the need for a separate PgBouncer layer. However, it does more than either a conventional connection pooler or a transparent TCP proxy. It understands Postgres protocol messages, parses the SQL it receives, and can break statements into work for individual shards and coordinate the results. This matters most for complex joins and aggregations, where the SQL sent to each shard can look very different from the original query. It also owns and preserves the client session state. When needed, it applies the relevant session state to work sent to Postgres.Each Postgres instance has a Neki sidecar running beside it. Once the router has planned a statement, it sends work over gRPC to a sidecar for each selected shard. The sidecar does not parse or plan the SQL. It forwards the work to Postgres over a pooled connection and streams the response back to the router.One query, two plansLet’s follow one query through its Neki plan and Postgres plan.Say we have an orders table sharded on user_id using xxhash.SELECT id, total_cents