pgagroal vs SPQR

pgagroal is a free, self-hosted PostgreSQL connection pool for Linux and macOS. It supports per-user and per-database connection limits, pool prefill, idle connection removal, and connection validation. Administrators can enable or disable database access and choose graceful or fast shutdown. Remote management and command-line tools handle runtime administration and user management. Monitoring exports Prometheus metrics and includes a Grafana 12 dashboard. Authentication can use database-backed queries or a user vault for credentials. If a PostgreSQL server can no longer accept writes, pgagroal can trigger an external failover workflow. The project lists TLS v1.2+ and describes both server-only and mutual certificate authentication. It works with PostgreSQL-compliant drivers including pgjdbc, Npgsql, and pq. Tested systems listed include Fedora 38+, RHEL 9.x, Rocky Linux 9.x, FreeBSD, and OpenBSD; releases list packages through Fedora 42/43, RHEL 10, and Rocky Linux 10. The repository identifies a BSD-3-Clause license. GitHub is used for questions, issues, feature requests, and code contributions.

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.