If you run MySQL InnoDB Cluster or ClusterSet, MySQL Router is the free, matching router. If you are a MariaDB Enterprise customer, MariaDB MaxScale adds query-level read/write splitting, transaction replay and automatic failover, but it is proprietary since 25.01. If you only need clients to reach the current primary, HAProxy is simpler, though it does not understand SQL. On AWS, Amazon RDS Proxy is the managed pooler for RDS and Aurora MySQL. If the real problem is that one primary is not enough, Vitess and Apache ShardingSphere shard MySQL behind a proxy, which is a much larger change than swapping proxies.
ProxySQL is a GPL v3, protocol-aware proxy for MySQL, Percona Server and MariaDB and, since its 3.x line, PostgreSQL. Backends are grouped into hostgroups, and query rules route, rewrite, cache, mirror or block statements; it multiplexes many client connections onto fewer backend connections and follows failovers in Galera, Group Replication and Aurora. On 5 November 2026 it shipped 3.0.12 (Stable), 3.1.12 (Innovative) and 4.0.12 together.
ProxySQL is very capable, and most teams that move away do so for one of these reasons:
- Configuration model. Changes are made in an in-memory admin database, then loaded to runtime and saved to disk, which in our reading has a real learning curve (editorial).
- More proxy than the topology needs. An InnoDB Cluster already publishes its own metadata, which MySQL Router reads directly; simple primary-and-replica setups may only need TCP failover (editorial).
- Release tiers. Features ship in three parallel tiers, and several newer PostgreSQL features are only in the Innovative tier, so you have to choose a tier deliberately.
- Vendor alignment and support. MariaDB Enterprise and AWS customers may prefer a proxy from their database vendor; ProxySQL's support plans and ProxySQL.Cloud have no published prices.
- Scaling writes. ProxySQL routes and splits traffic but does not shard data across primaries; that needs a sharding layer.
Planned head-to-head pages: ProxySQL vs MySQL Router and MariaDB MaxScale vs ProxySQL. For background on the two engines, see MariaDB vs MySQL; for PostgreSQL poolers, see PgBouncer alternatives.
Quick picks
Free GPL v2 router that reads cluster metadata and follows the primary, with automatic read/write splitting.
Query-level read/write splitting, transaction replay and monitor-driven failover for MariaDB.
Mature TCP load balancer with MySQL health checks and long LTS branches.
Managed pooling and faster Multi-AZ failover for RDS and Aurora MySQL.
Apache 2.0, CNCF-graduated sharding with online resharding, behind a MySQL-protocol router.
How we chose
We considered MySQL Router, MariaDB MaxScale, HAProxy, Amazon RDS Proxy, Vitess, Apache ShardingSphere and PostgreSQL poolers such as PgBouncer. To be included, a product had to sit between applications and MySQL-family servers, be actively developed or sold in November 2026, and document its routing and licensing on an official page. PostgreSQL-only poolers are covered on the PgBouncer alternatives page instead.
MariaDB MaxScale is included even though it changed licence: from 25.01 (January 2025) it is closed source and production use needs a MariaDB Enterprise subscription, and the older BSL releases are no longer maintained according to its GitHub README. It is still sold and developed, so it is a real option for MariaDB Enterprise customers, but not for teams that want open source.
The order is not a ranking. Router and proxy replacements come first, then the managed AWS option, then sharding layers that change the architecture.
At a glance
| Option | Licence | Databases | Read/write splitting | Failover handling | Main trade-off |
|---|---|---|---|---|---|
| MySQL Router | GPL v2 (commercial with MySQL Enterprise) | MySQL InnoDB Cluster and ClusterSet | Yes (access_mode=auto, classic protocol) | Follows primary from cluster metadata | Built around InnoDB Cluster; no query rules |
| MariaDB MaxScale | Proprietary from 25.01; Enterprise subscription | MariaDB Server, Galera | Yes, query level | Monitor-driven failover and switchover | Not open source; MariaDB-focused |
| HAProxy | GPL v2 (Enterprise commercial) | Any TCP database | By port only | Health checks remove failed servers | No pooling or SQL awareness |
| Amazon RDS Proxy | AWS managed service | RDS and Aurora MySQL, MariaDB (also PostgreSQL, SQL Server) | Read-only endpoints for Aurora and Multi-AZ DB clusters | Tracks the writer through Multi-AZ failover | AWS only; per vCPU-hour cost |
| Vitess | Apache 2.0 | MySQL and Percona Server 8.0 and 8.4 | Routes by shard (VSchema) | VTOrc reparenting | Many components; sharded SQL limits |
| Apache ShardingSphere | Apache 2.0 | MySQL, MariaDB and PostgreSQL protocols | Yes, by rules | Not documented in the pages checked | Large framework with its own DistSQL |
MySQL Router
MySQL Router is Oracle's routing component of InnoDB Cluster. You bootstrap it against a cluster, and it reads the cluster metadata to send read-write connections to the current primary and read-only connections to secondaries or read replicas, following failovers and switchovers without DNS changes. It has had a connection pool since 8.0.29, connection sharing since 8.0.32, and automatic read/write splitting on one port (6450 by default) when access_mode=auto, connection sharing and the classic protocol are used.
Its release model changed in July 2026: Router 26.7 started a single version line, the 8.4 and 9.7 Router series were discontinued, and 26.10.0 (20 October 2026) supports MySQL 8.4, 9.7 and 26.10. ProxySQL 4.0.12 also added a MySQL Router compatibility plugin that reads InnoDB Cluster metadata (source builds only). See ProxySQL vs MySQL Router.
- Designed around InnoDB Cluster metadata; classic replication, Galera, MariaDB and PostgreSQL are not its target.
- No query rules for rewriting, caching or blocking statements.
- Read/write splitting needs connection sharing and the classic protocol, and the Router must not be older than the server series it routes to.
MariaDB MaxScale
MaxScale is MariaDB plc's database proxy. Its Readwritesplit router splits reads and writes at query level, can replay transactions on a replacement server and offers causal reads to avoid stale reads from lagging replicas; the MariaDB Monitor performs automatic failover and switchover. Other routers cover connection-level balancing, simple sharding by database, binlog serving, Kafka CDC, mirroring and workload capture and replay. 25.10.4 (17 September 2026) is current.
The licence is the deciding factor. From 25.01 (16 January 2025) MaxScale is closed source, and MariaDB's FAQ says production use needs an active MariaDB Enterprise subscription; it is included in all three Enterprise Platform tiers, priced by quote. Older releases remain under the Business Source License, but the GitHub README says that version is no longer supported or maintained. See MariaDB MaxScale vs ProxySQL.
- Proprietary since 25.01, so it is not a route to open source.
- Designed and tested for MariaDB; MySQL-protocol servers may work but are not the target, and no PostgreSQL support is documented.
- Enterprise Platform pricing is not published.
HAProxy
HAProxy is a general TCP and HTTP load balancer. In mode tcp it forwards each MySQL connection to a healthy server, using option mysql-check, scripted tcp-check sequences, HTTP checks against an agent or external scripts to decide which servers are up. A common pattern is a write port that points at the primary and a read port that spreads connections across replicas. Current branches include 3.4 LTS (3.4.7, 14 October 2026, end of life 2031-Q2).
It replaces ProxySQL only where you did not use ProxySQL's SQL-level features. HAProxy does not parse statements, pool connections or multiplex them, so query rules, read/write splitting by statement and connection savings are lost (editorial).
- Not database-aware: no pooling, no read/write splitting by statement and no query rules.
- Built-in MySQL checks show a server is up, not whether it is the primary, so role detection needs a custom check.
- Database authentication is left to the servers.
Amazon RDS Proxy
RDS Proxy is AWS's managed proxy for Aurora MySQL, RDS for MySQL and RDS for MariaDB, as well as PostgreSQL and SQL Server engines. It reuses database connections after each transaction (multiplexing), pins sessions when sharing is unsafe, tracks the writer through Multi-AZ failovers (AWS says failover time can drop by up to 66% for RDS Multi-AZ DB instances) and supports IAM authentication with credentials in Secrets Manager.
Pricing is per vCPU-hour of the instance behind the proxy (0.015 USD in US East (N. Virginia) on 8 October 2026). It has no query rules, so it replaces ProxySQL's pooling and failover handling but not its routing, rewriting or caching. AWS itself references ProxySQL for low-downtime upgrades of some Multi-AZ deployments. See Amazon RDS Proxy explained.
- AWS only; the proxy must be in the database's VPC and cannot be publicly accessible.
- For RDS instances a proxy targets only the writer, not a read replica.
- AWS documents an average of about 5 ms added latency.
Vitess
Vitess is a CNCF-graduated clustering system that shards MySQL. Applications connect to VTGate, a stateless proxy that speaks the MySQL protocol and routes or scatters queries to shards using the keyspace's VSchema; VTTablet pools connections to each MySQL instance, VTOrc handles failover, and VReplication powers online resharding and MoveTables migrations. Vitess 24 (April 2026, 24.0.5 on 13 October 2026) supports MySQL and Percona Server 8.0 and 8.4, and is the last release with 8.0 support.
Choose it when the limit is write capacity rather than proxy features. Sharded keyspaces have documented limits: multi-shard transactions are best-effort unless TWOPC mode is used, and stored procedures run only on unsharded keyspaces or a targeted shard. PlanetScale, whose founders co-created Vitess, sells it as a managed service; see the PlanetScale profile.
- Many components to operate: VTGate, VTTablet, a topology service, VTOrc and MySQL.
- Sharding keys (vindexes) must be designed up front, and several SQL features are limited on sharded keyspaces.
- Far more change than replacing a proxy; MySQL 8.0 estates also need an 8.4 plan after v24.
Apache ShardingSphere
ShardingSphere adds sharding, read/write splitting, distributed transactions, encryption and masking on top of existing databases. ShardingSphere-Proxy is a server that speaks the MySQL, MariaDB and PostgreSQL protocols, so any compatible client can connect; ShardingSphere-JDBC does the same inside a Java application with no extra server. Rules are written in YAML or managed with DistSQL, its SQL-like rule language.
It suits estates that want one rule-based layer across MySQL and PostgreSQL databases rather than a new distributed database. Releases have slowed: 5.5.3 is current and came about a year after 5.5.2, and it removed SQL formatting and the logging rule.
- Large framework with its own concepts and DistSQL, so the learning curve is steep.
- Pooling, authentication and failover details were not documented on the pages we checked.
- Sharded SQL compatibility depends on its parser and rules, so complex queries need checking.
When to stay with ProxySQL
Stay with ProxySQL if you rely on its query rules (routing by pattern, rewriting, caching, mirroring or blocking a bad query during an incident), on connection multiplexing for many short-lived clients, or on one proxy layer across several MySQL topologies and PostgreSQL. None of the alternatives here covers all of that in one open source component. If the configuration model is the pain, ProxySQL Cluster and configuration management usually help more than a migration (editorial).
Switching makes most sense when your topology has a native router (MySQL Router for InnoDB Cluster, MaxScale for MariaDB Enterprise), when you only need TCP failover (HAProxy), when you want AWS to run the proxy (RDS Proxy), or when you need to shard (Vitess, ShardingSphere).
Frequently asked questions
What is the best open source alternative to ProxySQL?
For InnoDB Cluster, MySQL Router (GPL v2). For plain TCP routing, HAProxy (GPL v2). For sharding, Vitess and Apache ShardingSphere (both Apache 2.0). MariaDB MaxScale is no longer open source for current versions.
Is MariaDB MaxScale still open source?
No. From version 25.01 (January 2025) it is closed source, and production use needs a MariaDB Enterprise subscription. Versions up to 24.02 stay under the Business Source License, which converts each version to GPL v2 or later on its change date (10 April 2027 for 24.02), but the GitHub README says that edition is no longer maintained.
Can HAProxy replace ProxySQL?
Only for connection-level failover and load balancing. HAProxy does not parse SQL, pool connections or split reads and writes by statement.
Does ProxySQL work with PostgreSQL?
Yes, since the 3.0 line, with separate pgsql_* configuration tables; the home page lists PostgreSQL 13 to 18. For PostgreSQL-only pooling, see the PgBouncer alternatives page.
Do I need Vitess or just a proxy?
A proxy is enough when one primary can take your writes and replicas take the reads. Vitess is for when a single primary is no longer enough and you are ready to shard.
Sources
- ProxySQL home page
- Announcing ProxySQL 3.0.12, 3.1.12 and 4.0.12
- MySQL Router manual
- MySQL Router release notes
- MariaDB MaxScale licensing FAQ
- Introducing MariaDB MaxScale 25.01 GA
- MaxScale 25.10.4 release notes
- HAProxy home page and branches
- Amazon RDS User Guide: Amazon RDS Proxy
- Amazon RDS FAQs (RDS Proxy)
- Vitess documentation
- Apache ShardingSphere GitHub repository
Checked November 2026.
How we research these guides: our editorial method.