ProxySQL vs MySQL Router: Rules or InnoDB Cluster Routing? (2026)

Quick verdict

Short answer

If you run MySQL InnoDB Cluster or ClusterSet and mainly need applications to follow the primary, MySQL Router is the bundled, low-configuration choice: bootstrap it from the cluster and failovers need no application change. Choose ProxySQL when you have classic replication, Galera, Group Replication without the AdminAPI, Aurora or RDS, or when you want query rules that route, rewrite, cache, mirror or block statements. Both are free. Note the 2026 version changes: MySQL Router now ships as a single 26.x line, and ProxySQL ships three tiers (3.0 Stable, 3.1 Innovative and 4.0) released together.

How we know: This comparison is research-based: supported topologies, routing and read/write splitting, connection reuse, release models and licences were checked against ProxySQL and MySQL Router documentation, release notes and licence files on 7 November 2026. We have not deployed either product, so nothing here is a measured result.

ProxySQL is an open source (GPL v3) proxy that speaks the MySQL protocol, and since the 3.0 line also PostgreSQL. Backends are grouped into hostgroups, and query rules match statements by pattern, user or schema to route, rewrite, cache, mirror or block them. Configuration lives in an in-memory admin database changed with SQL and loaded to runtime without a restart. On 5 November 2026 the project shipped 3.0.12 (Stable), 3.1.12 (Innovative) and 4.0.12 (Plugin Chassis / AI) together; 2.7 is an LTS line that gets only security and severe bug fixes.

MySQL Router is Oracle's lightweight router and part of MySQL InnoDB Cluster, alongside Group Replication and MySQL Shell. It is usually bootstrapped against a cluster and then reads the cluster metadata to send read-write traffic to the primary and read-only traffic to secondaries or read replicas. Since Router 26.7 (28 July 2026) it has a single release line; the 8.4 and 9.7 Router series are discontinued, and 26.10.0 (20 October 2026) supports MySQL Server 8.4, 9.7 and 26.10.

Router follows a cluster; ProxySQL follows rules. MySQL Router gets its routing decisions from InnoDB Cluster metadata, so it needs little configuration but expects that topology. ProxySQL gets its decisions from hostgroups, monitors and rules you define, so it fits more topologies but asks more of you.

Side by side

Aspect	ProxySQL	MySQL Router
Main design target	Any MySQL-family topology: replication, Galera/PXC, Group Replication, Aurora and RDS; PostgreSQL 13 to 18 in 3.x	MySQL InnoDB Cluster, ClusterSet and their read replicas
How topology is learned	Configured hostgroups plus monitors for replication, Galera, Group Replication and Aurora	Bootstrap from the cluster; metadata-cache destinations follow primary changes
Read/write splitting	Query rules send matching statements to writer or reader hostgroups	Separate read-write and read-only ports, or automatic splitting on one port (6450 by default) with access_mode=auto
Connection reuse	Multiplexing of client connections onto backend connections, disabled per connection by transactions, locks, user variables, temporary tables and similar state	Connection pool (8.0.29) and connection sharing (8.0.32), enabled per route with connection_sharing
Query-level features	Rewrite, result cache, mirroring, blocking and firewall whitelisting	None of these; routing decisions only, with per-session overrides via ROUTER SET access_mode
Multi-site routing	Rules and hostgroups you define	InnoDB ClusterSet: follow the primary cluster or pin to a target cluster via MySQL Shell setRoutingOption
Configuration and HA of the proxy	SQL admin interface; ProxySQL Cluster syncs configuration between nodes	Bootstrapped config file; usually one Router per application host
Release model	3.0.x Stable, 3.1.x Innovative and 4.0.x released together; 2.7 LTS security fixes only	Single version line since 26.7; Router must not be older than the server series it routes to
Licence and price	GPL v3, free; Professional and Enterprise support by quote	GPL v2 Community release, free; commercial licence with MySQL Enterprise Edition, priced through MySQL Sales
Main trade-off	Very flexible, but a configuration model with a learning curve	Little to configure, but tied to InnoDB Cluster metadata

Key differences

Topology: one cluster type versus many

MySQL Router is built for Oracle's own high availability stack. When you bootstrap it against an InnoDB Cluster, it writes a configuration whose destinations use metadata-cache://, so it learns which member is primary from the cluster itself and follows failovers and switchovers without DNS or application changes. For InnoDB ClusterSet, each Router can follow whichever cluster is primary, or be pinned to a named cluster with MySQL Shell's setRoutingOption() and target_cluster. Classic asynchronous replication, Galera, MariaDB and PostgreSQL are not its target.

ProxySQL does not depend on any one cluster manager. You list servers in hostgroups, and its monitors track read-only flags, Galera, Group Replication and Aurora topologies to move servers between writer and reader hostgroups. That makes it the more common choice for mixed or non-Oracle topologies, including managed MySQL on AWS. ProxySQL 4.0.12 also adds a MySQL Router compatibility plugin that reads InnoDB Cluster metadata, but in that release it is available in source builds only, so treat it as early.

Read/write splitting

MySQL Router has two approaches. The traditional one is separate ports for read-write and read-only connections, with the application choosing. The newer one is automatic splitting on a single port: it needs access_mode=auto, connection_sharing=1, the classic protocol and a metadata-cache destination with role PRIMARY_AND_SECONDARY. Bootstrap creates such a route on port 6450 by default, and a session can override the decision with ROUTER SET access_mode or query attributes.

ProxySQL splits by rule, by listening port or by query digest. Its read/write split guide shows the simplest regex version, which sends SELECT ... FOR UPDATE to the writer hostgroup and other SELECT statements to readers, but warns against using that generic form in production; it recommends routing specific, identified queries (for example by digest) to replicas instead:

-- ProxySQL admin interface: generic split from the ProxySQL guide
-- (the guide advises targeted rules for production)
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*FOR UPDATE', 1, 1),
       (2, 1, '^SELECT', 2, 1);
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

Rules can also match on user or schema, which lets you send a reporting user to replicas only. The same mechanism handles rewriting, caching and blocking, which MySQL Router does not offer.

Connection reuse and session state

Both can share backend connections, and both have to protect session state. ProxySQL multiplexes client connections onto fewer backend connections, and its documentation lists the cases that turn multiplexing off for a connection: an open transaction, table locks, GET_LOCK(), queries with user variables, SQL_CALC_FOUND_ROWS, temporary tables, text-protocol PREPARE and SQL_LOG_BIN=0, some of them permanently for that connection. Applications that use these heavily get less reuse.

MySQL Router added a connection pool in 8.0.29 and connection sharing in 8.0.32, which returns idle server connections to the pool for other clients. Sharing is off by default and enabled per route. Because automatic read/write splitting depends on connection sharing, the same caveat applies to it: session state is reset when Router has to use change_user or reset_connection, so check your driver and session settings before turning it on.

Release models and versions in 2026

MySQL Router moved to a single release line with 26.7 in July 2026. The last 8.4 and 9.7 Router releases were 8.4.10 and 9.7.1 (16 June 2026), and the manual says the latest Router supports all supported MySQL Server versions. In practice: run the newest Router, and never one older than the server series it routes to.

ProxySQL releases three tiers together: 3.0.x Stable for production, 3.1.x Innovative with newer features (for example the native PostgreSQL backend in 3.1.12), and 4.0.x with a plugin framework. The 5 November 2026 releases fixed eight security issues across the tiers. Pick the tier deliberately and keep it patched; the 2.7 LTS line gets only security and severe bug fixes.

Pricing and licensing

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

MySQL Router. The Community release is free under GPL v2. A commercial release is covered by Oracle's MySQL commercial licences, and the MySQL Enterprise Edition page lists Router among the Enterprise components; mysql.com publishes no price and directs buyers to MySQL Sales. Router itself carries no separate charge.

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

Where each one leads

ProxySQL strengths

Query rules route, rewrite, cache, mirror or block statements, and change at runtime
Works with many topologies: replication, Galera/PXC, Group Replication, Aurora and RDS
Connection multiplexing for many short-lived application connections
One proxy layer for MySQL-family and PostgreSQL databases in the 3.x line
ProxySQL Cluster keeps configuration in sync across proxy nodes

MySQL Router strengths

Bootstraps from InnoDB Cluster, so there is little to configure
Follows failovers and ClusterSet switchovers from cluster metadata without DNS changes
Maintained by the MySQL team and released alongside the server
Automatic read/write splitting on one port with per-session overrides
Runs on Linux, Windows and macOS

Limitations

ProxySQL limitations

Admin tables, load to runtime and save to disk take time to learn
Multiplexing is disabled for connections that use transactions, locks, user variables or temporary tables
Newer PostgreSQL features sit in the Innovative tier, and some 4.0 plugins need source builds
No published prices for support plans

MySQL Router limitations

Built around InnoDB Cluster metadata; other MySQL topologies, MariaDB and PostgreSQL are not its target
Automatic read/write splitting needs connection sharing and the classic protocol
No query rewriting, caching, mirroring or blocking
Router must not be older than the server series it routes to

When to choose each

Choose ProxySQL if

You run classic replication, Galera, Aurora or RDS rather than InnoDB Cluster
You want to route by user, schema or query pattern
You need to block or rewrite a problem query at the proxy during an incident
You want one proxy for MySQL and PostgreSQL estates

Choose MySQL Router if

You run InnoDB Cluster or ClusterSet and want the supported router
You want applications to follow the primary with minimal configuration
You need ClusterSet routing to the primary cluster or a pinned target cluster
You prefer a component released and supported by Oracle alongside MySQL Server

When neither is right

You run MariaDB Enterprise and want vendor-supported failover and transaction replay: see MariaDB MaxScale vs ProxySQL.
You need horizontal sharding rather than routing to replicas: look at Vitess or Apache ShardingSphere.
You are on Amazon RDS or Aurora and mainly need managed pooling and faster failover: see Amazon RDS Proxy.
You only need TCP failover to one endpoint: a generic balancer such as HAProxy may be enough.

Final recommendation

Bottom line

For InnoDB Cluster and ClusterSet, MySQL Router is the natural default: it is free, bootstraps from the cluster and handles primary changes with almost no configuration. For anything else in the MySQL family, or when you want query-level control, ProxySQL is the more flexible tool, provided you invest in its configuration model and choose its release tier deliberately. Some InnoDB Cluster users still pick ProxySQL for its rules; if so, keep an eye on its MySQL Router compatibility plugin as it matures.

Frequently asked questions

Can ProxySQL replace MySQL Router for InnoDB Cluster?

It can route to InnoDB Cluster members using its Group Replication monitoring, and ProxySQL 4.0.12 adds a MySQL Router compatibility plugin that reads InnoDB Cluster metadata, available only in source builds in that release. MySQL Router remains the component Oracle documents for InnoDB Cluster and ClusterSet.

Does MySQL Router split reads and writes?

Yes. Either use separate read-write and read-only ports, or enable automatic splitting with access_mode=auto, connection_sharing=1, the classic protocol and a metadata-cache destination with role PRIMARY_AND_SECONDARY. Bootstrap creates such a route on port 6450 by default.

Which MySQL Router version should I run in 2026?

The latest. Since 26.7 (July 2026) there is one release line; the 8.4 and 9.7 Router series are discontinued, and Router 26.10 supports MySQL Server 8.4, 9.7 and 26.10.

Which ProxySQL tier is for production?

The project labels 3.0.x as Stable, 3.1.x as Innovative and 4.0.x as the plugin and AI tier. Most production users should run the Stable tier unless they need a feature only available in a newer tier.

Are both free?

Yes. ProxySQL is GPL v3 with optional paid support by quote. MySQL Router Community is GPL v2; a commercial licence comes with MySQL Enterprise Edition, priced through MySQL Sales.

Sources

Checked November 2026.

How we research comparisons: our editorial method.