MariaDB High Availability
ProxySQL vs MaxScale (and HAProxy) in front of MariaDB and Galera: which one should you choose?
In front of a MariaDB cluster, you need a layer that sends each connection to the right server, and stops sending it to a failed node. ProxySQL and MaxScale understand SQL, HAProxy only sees TCP. Here's what each one brings, what it costs to operate, and the MaxScale licence change to know about before choosing.
SQL proxy or TCP load balancer: two different jobs
A TCP load balancer like HAProxy forwards bytes. It knows whether a server answers a health check, not what the query contains. It's used with one port for writes and another for reads, and the application picks the right port.
A SQL proxy like ProxySQL or MaxScale reads the MySQL protocol. It can send SELECTs to replicas and everything else to the primary on a single port, pool connections, block or rewrite specific queries, and track replication or Galera state to pull out a lagging node. The trade-off: it has to be configured, monitored, and its side effects understood.
Either way, the proxy doesn't replace topology management. With asynchronous replication, something has to promote a new primary: MaxScale can, ProxySQL and HAProxy can't. Signal18 Replication Manager drives the failover and updates ProxySQL, MaxScale or HAProxy right after.
ProxySQL: the open source Swiss army knife
ProxySQL is a GPLv3 proxy that works with MySQL and MariaDB alike. Servers are grouped into hostgroups (writer, reader, backup) and query rules decide where each query goes. The same rules can cache, rewrite, throttle or block specific queries.
For Galera, the mysql_galera_hostgroups table natively handles the single-writer model: ProxySQL watches each node's wsrep state, keeps max_writers active writers, fails over to a backup writer if that node goes down, and removes a node that lags too far behind from reads.
Its standout feature is multiplexing: thousands of application connections share a few dozen connections to MariaDB. Common session variables that ProxySQL tracks (character set, sql_mode, time zone…) don't get in the way. An open transaction, however, suspends sharing for that connection until it ends, and some states disable it until the connection closes: temporary tables, locks, untracked session variables. It's per connection, not the whole pool, but an ORM that sets such state on every request loses most of the benefit.
The trade-off is configuration through a SQL admin interface, in three layers (memory, runtime, disk) that must be loaded and saved explicitly. A change left in memory, never pushed to runtime or never written to disk, is a classic ProxySQL incident.
MaxScale: MariaDB integration, with a licence to check
MaxScale is MariaDB plc's proxy. Its readwritesplit router splits reads and writes, and can guarantee that a read sees the same session's previous write (causal_reads, which needs MariaDB 10.2.16 or later; with Galera, only the fast* modes work, from MaxScale 24.02.5) or replay a transaction interrupted by a failover (transaction_replay).
It ships its own monitors: galeramon for Galera, and mariadbmon for asynchronous replication, which can promote a replica automatically. It's the only one of the three that handles failover itself. It remains built for MariaDB: it speaks the MySQL protocol, but its advanced features target MariaDB.
The first thing to check: the licence. Since version 25.01 (January 2025), MaxScale is under a proprietary commercial licence: production use requires a MariaDB Enterprise subscription. Earlier versions were released under the Business Source License (free in production with fewer than three servers), each converting to GPL on its own date. As of September 28, 2026, the 23.08 and earlier branches have moved to GPL (23.08 on September 21, 2026); 24.02 and 24.08 stay under BSL until 2027. Without a subscription and beyond two servers, all that's left are GPL branches that won't get new features.
HAProxy: simple, robust, SQL-unaware
HAProxy does one thing: send a TCP connection to a healthy server. In front of Galera, it's paired with an HTTP health check script (the classic clustercheck) that answers "OK" only if the node is synced. One server active for writes, the others as backup: you get the single-writer model for new connections, without a SQL proxy. Watch out when the primary comes back: sessions already open on a backup stay there unless you add on-marked-up shutdown-backup-sessions.
No automatic read/write split, no pooling, no rules. But a twenty-line configuration, a tiny memory footprint and very predictable behaviour. It's often the right choice when the application already knows how to use two ports, or when the load doesn't justify a SQL proxy.
Side-by-side comparison
None wins on every line: the choice depends on what the application needs.
| Criterion | ProxySQL | MaxScale | HAProxy |
|---|---|---|---|
| Layer | SQL protocol (L7) | SQL protocol (L7) | TCP (L4) |
| Licence | GPLv3, free | 25.01+: proprietary, Enterprise subscription for production. 24.02 / 24.08: BSL until 2027. 23.08 and earlier: now GPL | GPLv2, free |
| Read/write split | Yes, via query rules and hostgroups | Yes, readwritesplit router | No (one port per role) |
| Connection pooling | Yes, with multiplexing | Connection reuse, more limited | No |
| Query rules, rewrite, cache | Yes, very fine-grained | Yes, through filters | No |
| Galera awareness | mysql_galera_hostgroups (single writer, backup writers) | galeramon monitor | Through an HTTP health check (clustercheck) |
| Async replication failover | Follows the topology; promotion done by an external tool | Built in (mariadbmon) | No; external tool |
| MySQL support | MySQL and MariaDB | Designed for MariaDB; advanced features MariaDB-only | Any (protocol-agnostic) |
| Configuration | SQL admin interface, memory/runtime/disk layers | Config file, REST API, maxctrl, GUI | Config file |
| Operational complexity | Medium to high | Medium | Low |
Minimal configurations in front of a 3-node Galera
Examples to adapt (addresses, monitoring users, passwords). They illustrate the single-writer model, not a complete production setup.
ProxySQL: Galera hostgroups, one active writer
-- ProxySQL admin interface (port 6032)
-- Prerequisite: a monitoring user (mysql-monitor_username)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
(10, 'db1', 3306), (10, 'db2', 3306), (10, 'db3', 3306);
INSERT INTO mysql_galera_hostgroups
(writer_hostgroup, backup_writer_hostgroup, reader_hostgroup,
offline_hostgroup, active, max_writers, writer_is_also_reader,
max_transactions_behind)
VALUES (10, 12, 11, 13, 1, 1, 2, 100);
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;MaxScale: Galera monitor and read/write split
# /etc/maxscale.cnf (sections [db1] [db2] [db3] not shown)
[Galera-Monitor]
type=monitor
module=galeramon
servers=db1,db2,db3
user=maxscale_monitor
password=...
monitor_interval=2s
[RW-Split]
type=service
router=readwritesplit
cluster=Galera-Monitor
user=maxscale
password=...
[RW-Listener]
type=listener
service=RW-Split
port=3306HAProxy: one writer, two backups, clustercheck health check
# haproxy.cfg — clustercheck answers over HTTP on port 9200
listen galera-write
bind *:3306
mode tcp
option httpchk
default-server port 9200 inter 2s fall 3 rise 2
server db1 10.0.0.1:3306 check
server db2 10.0.0.2:3306 check backup
server db3 10.0.0.3:3306 check backupWhich one for which situation?
Single-writer Galera, application already manages its connections
HAProxy + clustercheck. The simplest to operate.
Many short-lived connections (PHP, serverless), reads to spread
ProxySQL: multiplexing and read/write split.
Need to block, rewrite or cache queries without touching the code
ProxySQL and its query rules.
MariaDB environment with an Enterprise subscription
MaxScale: deepest integration, built-in failover and causal reads.
Asynchronous replication with automatic failover, no subscription
Replication Manager for failover, ProxySQL or HAProxy in front.
Mixed MySQL and MariaDB estate
ProxySQL or HAProxy, which treat both the same way.
Common pitfalls
- The proxy becomes a single point of failure. Run two behind a virtual IP (keepalived), or a local proxy on each application server.
- Splitting reads and writes without accounting for replica lag: a user saves, reloads the page and doesn't see the change. Cap the accepted lag or keep critical reads on the primary.
- Writing to several Galera nodes "because the proxy allows it": certification conflicts come back to the application as deadlocks. See Galera vs replication.
- Counting on ProxySQL multiplexing while the application sets session variables or temporary tables on every request: multiplexing is disabled on those connections and the pool barely helps anymore.
- Upgrading MaxScale to a 25.x release without checking the licence: in production, without a subscription, it isn't covered.
Our approach at RDEM Systems
We don't push a particular proxy. On replication topologies, Replication Manager drives failover and updates whichever proxy is in place, be it ProxySQL, HAProxy or MaxScale. In front of Galera, a proxy routing writes to a single node is the most common choice. A SQL proxy isn't mandatory though: on our own 3-node Galera cluster, application servers connect directly to the nodes, with layer-4 load balancing (IPVS).
If you already run a proxy, the MariaDB audit checks its configuration, its redundancy and how it behaves during a failover. For other everyday tools, see our MariaDB / MySQL DBA toolbox.
Frequently asked questions
Is MaxScale still free?
Since version 25.01 (January 2025), MaxScale is under a proprietary commercial licence and production use requires a MariaDB Enterprise subscription. Earlier versions were under the Business Source License (free in production with fewer than three servers) and move to GPL on a date specific to each version: as of September 28, 2026, the 23.08 and earlier branches are GPL, while 24.02 and 24.08 stay under BSL until 2027.
Does ProxySQL work with MariaDB and Galera?
Yes. ProxySQL is MariaDB-compatible and handles Galera natively through the mysql_galera_hostgroups table: one or more active writers, backup writers, and automatic exclusion of unavailable or desynced nodes (an SST donor can stay in service when wsrep_sst_donor_rejects_queries is off).
Is HAProxy enough in front of a Galera cluster?
Often, yes. With a health check that verifies the node's sync state and a single active server for writes, HAProxy provides the single-writer model. It doesn't split reads from writes: the application must target two distinct endpoints (typically two ports) if it wants to spread its reads.
Does the proxy handle primary failover?
Only MaxScale can promote a replica in asynchronous replication. ProxySQL and HAProxy follow the topology but promote nothing: you need a tool like Replication Manager to decide on failover and update the proxy.
Does your proxy hold up during a failover?
The MariaDB audit tests topology, proxy and failover, and checks that no component remains a single point of failure.
Start your managed MariaDB project
Let's discuss your database needs. Our DBA team advises you on the optimal architecture for your use case.
RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise