PgCat vs SPQR

PgCat is a free, open-source PostgreSQL pooler and proxy for self-hosted Linux deployments. Its stable features include transaction and session pooling. Read queries can be balanced across replicas and the primary, while health checks detect broken replicas and redirect queries to remaining servers. PgCat uses Tokio’s asynchronous runtime and a multithreaded design for multicore machines. Operators can view pooler statistics through the pgcat and pgbouncer admin databases or a Prometheus HTTP endpoint. Client and PostgreSQL server connections can use SSL/TLS, with MD5 and SCRAM-SHA-256 authentication supported. MD5 passthrough can use auth_query so cleartext passwords need not be stored in the configuration file. Docker deployment is documented, and a container image is published. Sharding syntax, comment parsing, automatic sharding, and mirroring are experimental. Transaction mode is enabled by default and does not support prepared statements, SET, or advisory locks. The project describes PgCat as stable and says it serves high query volumes in production. It is licensed under MIT.

SPQR is a self-hosted query router for horizontally scaling PostgreSQL through sharding. It can extract a sharding key from a query and route it to the relevant key range and shard when possible; keys can use one column or several. Queries can also specify a key or shard in a SQL comment. Applications connect using the PostgreSQL protocol, and the router and coordinator provide administrative consoles accessible through psql. SPQR supports one-phase and two-phase commit strategies; two-phase commit provides atomicity across shards and requires max_prepared_transactions greater than zero on each shard. The system can move data between shards to balance workload, and the project describes reducing transferred ranges to limit locking impact. Its documentation includes Docker and configuration-file deployment instructions. SPQR is free and distributed under the PostgreSQL Global Development Group License. The FAQ cautions that it is not suited to complex cross-shard queries, transactions modifying multiple shards or OLAP workloads, and reports a roughly 10–30% performance drop versus vanilla PostgreSQL depending on workload.