PgBouncer vs SPQR

PgBouncer is a self-hosted connection pooler for PostgreSQL. It reuses server connections to lessen the performance cost of opening new ones, and offers session, transaction, and statement pooling. Statement pooling does not allow multi-statement transactions. PgBouncer can send connections to databases on different hosts, but it has no built-in multi-host load balancing or failover detection; DNS round-robin, external TCP load balancers, DNS changes, or external tools are described as alternatives. It can track protocol-level prepared statements in transaction and statement modes when max_prepared_statements is non-zero. Authentication options include client certificates, SCRAM-SHA-256, LDAP, PAM, and HBA-based configuration. The features page lists default memory needs of 2 kB per connection. PgBouncer is free, with source releases and references to native packages and RPM and Debian repositories. It runs on Linux and Windows; MinGW is the documented supported Windows build environment. Building requires Libevent 2.0 or later, pkg-config, and a C11-capable compiler; TLS support also requires OpenSSL.

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.