DBLE vs SPQR

DBLE is free, open-source middleware for scaling MySQL through sharding. It uses the MySQL protocol and can replace MySQL in many cases without application code changes. Teams can configure hash, modulo, time-based, range-based, or custom sharding, along with global and ER tables. DBLE lists query routing, connection pooling, load balancing, automatic failover, read/write separation, master-slave expansion, and ZooKeeper cluster deployment. SQL support includes SQL 92 and MySQL dialect features such as joins, unions, grouping, ordering, and distinct queries; some features remain on its roadmap. Query optimization addresses global-table joins, sharded tables, ER relations, and subqueries. Distributed transactions use two-phase commit in normal or XA modes, with XA depending on MySQL 5.7 XA transactions, backend availability, and disk reliability. Security controls include password encryption, IP allowlists, and SQL denylists. Explain plans, MySQL-compatible slow logs, and slow-query reports support operations. DBLE is self-hosted on Linux and GPL-2.0 licensed. The open-source plan costs nothing.

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.