How Neki Router Solves Sharding and Connection Scaling in Distributed Postgres

Neki is a distributed database routing layer that sits between applications and sharded Postgres instances, managing both query routing and client connection handling. Unlike Postgres's traditional process-per-connection model, Neki routers handle client connections within their own processes, eliminating the memory and scheduling overhead that limits large-scale deployments. The router parses SQL, builds a topology-aware plan to determine which shards receive each query, and coordinates results across shards — replacing the need for a separate connection pooler like PgBouncer. Each Postgres instance runs a lightweight Neki sidecar that receives work from the router via gRPC, forwards it to Postgres over a pooled connection, and streams results back. Because routers are stateless and their cached data can be rebuilt, they can be added, resized, or removed independently as workloads change, giving operators two distinct scaling levers: shards for data and routers for connection and query processing capacity.