MariaDB MaxScale vs ProxySQL: Licence, Failover, Routing (2026)

Quick verdict

Short answer

Read this first: MaxScale is no longer an open source option. From version 25.01 (January 2025) MariaDB licenses it under a proprietary commercial licence, and its FAQ says production use needs an active MariaDB Enterprise subscription; the old BSL releases are no longer supported or maintained. So choose MariaDB MaxScale if you already buy, or plan to buy, MariaDB Enterprise Platform and want the vendor's proxy with automatic failover, transaction replay and causal reads for MariaDB. Choose ProxySQL if you want a free, open source proxy, run MySQL as well as MariaDB (or PostgreSQL), or want rule-based routing, rewriting and caching that you control.

How we know: This comparison is research-based: licences, packaging, routing, failover and pooling behaviour and release status were checked against MariaDB and ProxySQL documentation, release notes, licence files, FAQs and pricing pages on 7 November 2026. We have not deployed either product, so nothing here is a measured result.

MariaDB MaxScale is a plugin-based database proxy maintained by MariaDB plc. Routers decide where queries go (Readwritesplit for query-level splitting, Readconnroute for connection-level balancing, SchemaRouter for database-level sharding, Binlogrouter, Mirror, Diff and Kafka routers among others), monitors track the topology, and filters rewrite or mask traffic. The MariaDB Monitor can fail over and switch over MariaDB replication. The current release is 25.10.4 GA (17 September 2026). Since 25.01 it is proprietary and is sold as part of MariaDB Enterprise Platform; MariaDB plc has been privately owned by K1 Investment Management since September 2024.

ProxySQL is an open source (GPL v3) proxy for MySQL 5.7 to 9.x, Percona Server, MariaDB, Galera and Group Replication, Aurora and RDS, and PostgreSQL 13 to 18 in the 3.x line. Backends sit in hostgroups and query rules route, rewrite, cache, mirror or block statements. On 5 November 2026 it shipped 3.0.12 (Stable), 3.1.12 (Innovative) and 4.0.12 together, fixing eight security issues; 2.7 is an LTS line with security fixes only.

Commercial component versus open source tool. For new deployments this is not a free-versus-free comparison any more. MaxScale is part of a paid MariaDB subscription; ProxySQL is free software with optional paid support. If you use MySQL InnoDB Cluster instead, see ProxySQL vs MySQL Router.

Side by side

Aspect	MariaDB MaxScale	ProxySQL
Licence (current versions)	Proprietary since 25.01; 24.02 and older under BSL 1.1 (unsupported)	GPL v3
How it is sold	Included in MariaDB Enterprise Platform, Platform Plus and Platform Ultimate, quote only	Free; Professional and Enterprise support by quote
Supported databases	MariaDB Server and Enterprise Server, Galera, primary/replica setups; other MySQL-protocol servers not the design target; no PostgreSQL	MySQL 5.7 to 9.x, Percona Server, MariaDB, Galera/PXC, Group Replication, Aurora, RDS; PostgreSQL 13 to 18
Read/write splitting	Readwritesplit router classifies each query and sends writes to the primary	Query rules send matching statements to writer or reader hostgroups
Read consistency with lagging replicas	causal_reads modes using MASTER_GTID_WAIT	Rules and hostgroup settings; monitors move lagging or read-only servers
Failover	MariaDB Monitor performs automatic failover and switchover of MariaDB replication	Follows topology changes detected by its monitors; does not promote replicas itself
Mid-transaction failure handling	Transaction replay on a replacement server	Not documented in the pages checked
Connection reuse	Not documented as a separate pooling mode in the pages checked; Readwritesplit keeps backend connections per client session	Multiplexing of client connections onto fewer backend connections, disabled per connection by transactions, locks, user variables and similar state
Query-level features	Filters for masking and rewriting; Workload Capture and Replay, Diff router, Kafka CDC router	Rewrite, result cache, mirroring, blocking, firewall whitelisting
Proxy HA and configuration	Configuration files (maxscale.cnf); Kubernetes via the MariaDB Enterprise Kubernetes Operator	SQL admin interface with runtime reload; ProxySQL Cluster syncs configuration
Main trade-off	Deepest MariaDB integration with vendor support, but closed source and subscription only	Free and broad, but you build failover and routing behaviour from rules and external HA

Key differences

Licensing and what it means for new projects

Up to 24.02, MaxScale was source-available under the Business Source License 1.1. Its Additional Use Grant allowed free production use with fewer than three server instances (the FAQ phrases it as up to two MariaDB backend servers), and each version converts to GPL v2 or later on a change date (for 24.02, 10 April 2027). With 25.01 (16 January 2025) MariaDB moved MaxScale to a fully proprietary commercial licence, and the FAQ says production use of 25.01 and later needs an active MariaDB Enterprise subscription. The GitHub README says the open source version is no longer supported or maintained. In practice, running an old BSL release to avoid the subscription means running an unmaintained proxy.

ProxySQL stays GPL v3, and its home page describes the Community plan as always open source. You can run it in production without a contract and add Professional or Enterprise support if you want it. For teams that left MaxScale after the licence change, ProxySQL is the most direct open source replacement in this category, though it works differently, as the next sections show.

Read/write splitting and read consistency

MaxScale's Readwritesplit router classifies every statement and sends writes, and anything that must stay on the primary, to the primary, and reads to replicas, without rules you write yourself. Its causal_reads setting addresses replica lag: after a write, a later read from the same client (or from any client, in the global modes) waits on the replica with MASTER_GTID_WAIT until the write has replicated, so users read their own writes.

# maxscale.cnf (sketch): Readwritesplit service with causal reads
# causal_reads: none, local, global, fast, fast_global, universal, fast_universal
[RW-Split-Service]
type=service
router=readwritesplit
servers=server1,server2,server3
user=maxscale
password=secret
causal_reads=local
transaction_replay=true

If a replica does not catch up within causal_reads_timeout, the read is retried on the primary. The Readwritesplit reference notes that the router does not detect replication lag itself and needs a monitor such as the MariaDB Monitor.

ProxySQL splits by query rules that match a digest, pattern, user or schema and send statements to writer or reader hostgroups; its read/write split guide warns against a generic ^SELECT rule in production and recommends routing specific, identified queries to replicas. That is more work up front but gives precise control, and the same rules can rewrite, cache or block statements, which MaxScale handles through separate filters.

Failover and transaction replay

MaxScale can own failover. The MariaDB Monitor detects a failed primary, promotes a replica, redirects the other replicas and supports planned switchovers; a safe mode avoids failover when data loss is certain. With transaction_replay, Readwritesplit can replay an interrupted transaction on the new primary, which hides many failover errors from the application.

ProxySQL follows failovers rather than performing them. Its monitors check read-only flags and Galera, Group Replication and Aurora status, and move servers between hostgroups when the topology changes; promotion is left to the database cluster, an orchestrator or the managed service. That keeps ProxySQL topology-neutral, but you need a separate component in charge of promoting a MariaDB or MySQL replica in classic replication setups.

Connection handling and scope

ProxySQL multiplexes many client connections onto fewer backend connections, which helps with large numbers of short-lived application connections. Its documentation lists the cases that switch multiplexing off for a connection: open transactions, table locks, GET_LOCK(), user variables, SQL_CALC_FOUND_ROWS, temporary tables, text-protocol PREPARE and SQL_LOG_BIN=0. MaxScale is not documented as a multiplexing pooler in the pages we checked; its Readwritesplit keeps backend connections per client session, and its strengths lie in MariaDB-specific routers such as Binlogrouter, KafkaCDC and Workload Capture and Replay. ProxySQL also covers MySQL and PostgreSQL estates, which MaxScale does not target.

Pricing and licensing

MariaDB MaxScale. Current versions (25.01 and later) are proprietary and need an active MariaDB Enterprise subscription for production, according to MariaDB's MaxScale FAQ. The pricing page lists the MaxScale proxy as included in all three MariaDB Enterprise Platform tiers (Platform, Platform Plus and Platform Ultimate), priced by quote with no list prices published. The old BSL releases (24.02 and earlier) carry no fee for small deployments under the licence terms, but MariaDB says that version is no longer supported or maintained, so we do not present it as a purchasing option.

ProxySQL. Free under GPL v3. ProxySQL sells Professional support (24x7 support, priority bug fixes, architecture help and an administration web UI), Enterprise support (SLAs, health monitoring and alerting, custom feature development) and professional services; no prices are published, so these are quote-based. ProxySQL.Cloud, announced on 1 September 2026, was in preview with no published pricing.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

MariaDB MaxScale strengths

Query-level read/write splitting for MariaDB without hand-written routing rules
Monitor-driven automatic failover and switchover for MariaDB replication
Transaction replay and causal reads reduce failover errors and stale reads
MariaDB-specific routers: Binlogrouter, KafkaCDC, Diff and Workload Capture and Replay
Vendor support as part of a MariaDB Enterprise subscription

ProxySQL strengths

Free and open source under GPL v3, with optional paid support
Covers MySQL, MariaDB, Galera, Group Replication, Aurora, RDS and PostgreSQL
Rules that route, rewrite, cache, mirror or block statements at runtime
Connection multiplexing for many short-lived client connections
ProxySQL Cluster keeps configuration in sync across proxy nodes

Limitations

MariaDB MaxScale limitations

Closed source since 25.01; production use needs a MariaDB Enterprise subscription
Pricing is quote only, as part of Enterprise Platform tiers
The BSL open source version is no longer supported or maintained
Designed and tested for MariaDB; no PostgreSQL support documented

ProxySQL limitations

Does not promote replicas itself; needs an external failover owner for classic replication
Routing quality depends on the rules you write
Multiplexing is disabled for connections that use transactions, locks, user variables or temporary tables
Newer features sit in the Innovative and 4.0 tiers; choose the tier deliberately

When to choose each

Choose MariaDB MaxScale if

You already have, or plan to buy, a MariaDB Enterprise subscription
You want the proxy itself to fail over MariaDB replication and replay interrupted transactions
Read-your-writes consistency on replicas matters (causal reads)
You want vendor support for the whole MariaDB stack from one company

Choose ProxySQL if

You want an open source proxy with no subscription requirement
You run MySQL, Percona Server or PostgreSQL as well as MariaDB
You want rule-based control, query rewriting, caching or blocking
You need connection multiplexing for many short-lived connections
You are replacing an unsupported BSL MaxScale release

When neither is right

You run MySQL InnoDB Cluster: ProxySQL vs MySQL Router covers the bundled router.
You need horizontal sharding rather than replicas: look at Vitess or Apache ShardingSphere.
You use managed MariaDB or MySQL on AWS and mainly need pooling and faster failover: see Amazon RDS Proxy.
You only need TCP failover to a single endpoint: HAProxy with external health checks may be enough.

Final recommendation

Bottom line

For MariaDB Enterprise customers, MaxScale is the more integrated choice: it routes without hand-written rules, fails over MariaDB replication itself and replays interrupted transactions, and it comes with vendor support. For everyone else, the 25.01 licence change makes ProxySQL the default open source proxy for MariaDB and MySQL, as long as you pair it with a component that owns failover and invest in its rule-based configuration. Do not plan around the old BSL MaxScale releases; MariaDB no longer maintains them.

Frequently asked questions

Is MaxScale still open source?

No. Versions up to 24.02 were source-available under the Business Source License 1.1. From 25.01 (January 2025) MaxScale uses a closed-source commercial licence, and production use needs an active MariaDB Enterprise subscription.

Can I keep using an old BSL MaxScale for free?

The BSL allows free production use for small deployments (fewer than three server instances), and each version converts to GPL v2 or later on its change date (24.02 on 10 April 2027). However, the MaxScale GitHub README says that open source version is no longer supported or maintained, so it will not receive fixes.

Can ProxySQL replace MaxScale for MariaDB?

For routing and read/write splitting, yes: ProxySQL supports MariaDB and Galera. It does not promote replicas itself and has no direct equivalent to MaxScale transaction replay documented in the pages we checked, so plan failover separately.

Does MaxScale support PostgreSQL or MySQL?

MaxScale is designed and tested for MariaDB. Other MySQL-protocol servers may work but are not the design target, and no PostgreSQL support is documented. ProxySQL supports MySQL, MariaDB and PostgreSQL.

How much does each cost?

MaxScale is included in MariaDB Enterprise Platform tiers, priced by quote. ProxySQL is free under GPL v3, with paid support by quote.

Sources

Checked November 2026.

How we research comparisons: our editorial method.