ShardingSphere-Proxy vs SPQR

ShardingSphere-Proxy is a self-hosted database proxy that gives clients a database server interface over a binary protocol. Its listed client protocols are MySQL, PostgreSQL, openGauss, and Firebird. It distributes storage and computing across underlying databases through sharding, and provides distributed transactions with a hybrid XA and BASE engine. Read/write splitting balances reads using SQL semantics and awareness of database topology. Other capabilities include migration with sharding, federated queries, transparent encryption, and data masking.

You can deploy it from a binary distribution, as a Docker image, or with Helm. The binary requires Java JRE 8 or higher; Docker needs no additional dependency. For a MySQL backend, the Proxy ext-lib directory needs mysql-connector-j-8.4.0.jar. The project is free at free. Support for system databases and tables such as information_schema and pg_catalog is limited, and some graphical database clients may show errors.

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.