ProxySQL 3.0: PostgreSQL Support and What Changed for MySQL Users

ProxySQL 3.0 is the first ProxySQL series that speaks the PostgreSQL wire protocol as well as MySQL's. The current Stable release, 3.0.12, shipped on 5 November 2026, and the 2.7 series still receives security and severe-bug releases (2.7.4 on 20 October 2026). Teams searching for a "sql proxy" now ask two questions. Can ProxySQL sit in front of PostgreSQL in place of PgBouncer or Pgpool-II? And what changes for an existing MySQL deployment when it moves from 2.x to 3.0? A common first surprise is that apt-get upgrade leaves a 2.7 node on 2.7, because each series has its own package repository. This guide covers the PostgreSQL feature set as of November 2026, the MySQL-side changes, an upgrade runbook with a rollback point, and a factual comparison with PgBouncer and Pgpool-II.

Scope and review date: November 2026. This post covers ProxySQL 2.7.x and 3.0.x (Stable tier) on Linux packages, with notes on 3.1.x and 4.0.x. Versions, defaults, table definitions, and commands were checked against the ProxySQL GitHub release notes and proxysql.com documentation on 9 November 2026. They were not run in a lab, so rehearse every step on staging first.

Which ProxySQL 3 version should you run in November 2026?

Run 3.0.12. Since 3.0.6 (March 2026), ProxySQL publishes three tiers from the same release cycle. The multi-tier announcement calls 3.0.x Stable "the gold standard for production", 3.1.x Innovative "for early adopters", and 4.0.x AI/MCP "our experimental playground". On the GitHub releases page, 3.0.12 is marked Latest and 3.1.12 and 4.0.12 are pre-releases, all dated 5 November 2026.

The 3.0.12 release notes fix eight published security advisories (four high, four medium). That is reason enough to move off older 3.0 builds. If you stay on 2.7 for now, the 2.7.4 announcement describes it as a security and severe-bug release for the "2.7 LTS series", with fixes for 15 advisories.

# On each ProxySQL host
proxysql --version

Interpretation: the output starts with the build string, for example ProxySQL version 2.7.4-29-gbc3e363 for the current 2.7 release. Record it for every node before you plan the upgrade.

Some features in the 3.0 release notes are gated to the other tiers. The 3.0.11 notes say frontend RSA full authentication for caching_sha2_password, per-user X.509 policy, and frontend MariaDB ed25519 are 3.1/4.0 features. The 3.0.10 notes say mysql-passthrough_auth_enabled=true is refused on the Stable tier.

Is ProxySQL's PostgreSQL support production ready?

ProxySQL has not said so in a release note we could find. The 3.0.1 release notes (May 2025) say "the MySQL module is considered stable" and "the PostgreSQL module is still in beta". The 3.0.2 notes (August 2025) repeat that. From 3.0.3 onward, the Stable notes add PostgreSQL features and fixes without restating a status. The proxysql.com documentation describes ProxySQL as a proxy for MySQL and PostgreSQL without a beta label.

The 3.0.12 notes show how much is still settling. They fix PostgreSQL transaction recovery so "a disagreement between ProxySQL's tracker and the backend no longer aborts the process". They make prepared statements account for search_path and stop WITH HOLD cursors from leaking to another pooled session. Portal handling and LISTEN/NOTIFY through the proxy are new in 3.1.12 and 4.0.12, per the 3.0.12 announcement, so do not plan on them on 3.0.x.

What does ProxySQL 3.0 support for PostgreSQL?

PostgreSQL gets its own listeners and its own admin tables. The 3.0.1 notes list port 6132 for the PostgreSQL admin interface and 6133 for PostgreSQL traffic. The MySQL ports stay at 6032 and 6033. Configuration lives in pgsql_servers, pgsql_users, pgsql_query_rules, pgsql_replication_hostgroups, and pgsql_hostgroup_attributes, and you promote it with LOAD PGSQL ... TO RUNTIME.

• Protocol: simple queries and multiple statements per query since 3.0.0. The extended query protocol (Parse, Bind, Describe, Execute) arrived in 3.0.3. COPY ... FROM STDIN works through fast-forward from 3.0.1.
• Authentication: cleartext, MD5, and SCRAM-SHA-256. The default pgsql-authentication_method is 3, SCRAM-SHA-256. From 3.0.12, pgsql_users can hold stored SCRAM verifiers or MD5 secrets instead of cleartext passwords, with the restrictions listed in those notes.
• TLS: frontend and backend. Per-server backend TLS settings arrived in pgsql_servers_ssl_params in 3.0.8.
• Pooling: multiplexing and connection reuse, with tracking of session parameters, transactions, and savepoints since 3.0.1.
• Query rules: pgsql_query_rules and pgsql_query_rules_fast_routing match on user, digest, or pattern. A PostgreSQL-specific digest tokenizer arrived in 3.0.4.
• Monitoring: connect, ping, and read-only checks with pg_is_in_recovery() (3.0.1), and replication lag checks (3.0.6).
• ProxySQL Cluster: peer sync of the PostgreSQL tables from 3.0.8.

Check which interfaces a node is listening on before you open firewall rules:

-- ProxySQL admin, MySQL protocol: mysql -u admin -p -h 127.0.0.1 -P 6032
SELECT variable_name, variable_value
FROM global_variables
WHERE variable_name IN ('admin-mysql_ifaces', 'admin-pgsql_ifaces',
                        'mysql-interfaces', 'pgsql-interfaces');

Interpretation: expect 6032 and 6033 for MySQL, and 6132 and 6133 for PostgreSQL, unless you changed them. The proxysql.com variable reference shows a different default for pgsql-interfaces than the release notes and configuration guide, so trust what your node returns here.

How do you split PostgreSQL reads and writes in ProxySQL 3.0?

The pattern matches MySQL: define servers, pair a writer and a reader hostgroup, add users, then add query rules. Connect to the PostgreSQL admin interface with psql -h 127.0.0.1 -p 6132 -U admin -d admin, as the PostgreSQL configuration guide shows. Change the default admin credentials first.

-- On PostgreSQL: a login role for the ProxySQL monitor
CREATE ROLE proxysql_monitor LOGIN PASSWORD 'change-me';
GRANT pg_monitor TO proxysql_monitor;

Interpretation: the monitor variables page says the monitor user needs pg_monitor privileges for read-only checks. Allow the role in pg_hba.conf from the ProxySQL hosts.

-- ProxySQL PostgreSQL admin (port 6132)
UPDATE global_variables SET variable_value = 'proxysql_monitor'
  WHERE variable_name = 'pgsql-monitor_username';
UPDATE global_variables SET variable_value = 'change-me'
  WHERE variable_name = 'pgsql-monitor_password';
LOAD PGSQL VARIABLES TO RUNTIME;
SAVE PGSQL VARIABLES TO DISK;

INSERT INTO pgsql_servers (hostgroup_id, hostname, port) VALUES
  (1, '10.0.2.11', 5432),
  (2, '10.0.2.12', 5432),
  (2, '10.0.2.13', 5432);
INSERT INTO pgsql_replication_hostgroups (writer_hostgroup, reader_hostgroup, comment)
  VALUES (1, 2, 'orders cluster');
LOAD PGSQL SERVERS TO RUNTIME;
SAVE PGSQL SERVERS TO DISK;

Interpretation: once pgsql_replication_hostgroups has a row, the monitor runs pg_is_in_recovery() on every server in hostgroups 1 and 2 and places each one by its answer. The PostgreSQL tables reference notes that check_type is unused for PostgreSQL today. pgsql-monitor_writer_is_also_reader defaults to true, so the primary also serves reads in hostgroup 2.

INSERT INTO pgsql_users (username, password, default_hostgroup)
  VALUES ('orders_app', 'app-password', 1);
LOAD PGSQL USERS TO RUNTIME;
SAVE PGSQL USERS TO DISK;

INSERT INTO pgsql_query_rules
  (rule_id, active, username, match_digest, destination_hostgroup, apply)
VALUES
  (10, 1, 'orders_app', '^SELECT .* FOR (UPDATE|SHARE)', 1, 1),
  (20, 1, 'orders_app', '^SELECT ', 2, 1);
LOAD PGSQL QUERY RULES TO RUNTIME;
SAVE PGSQL QUERY RULES TO DISK;

Interpretation: anything without a matching rule goes to the user's default_hostgroup, the primary. Locking reads stay on the primary, and other SELECTs go to replicas. Because transaction_persistent defaults to 1 in pgsql_users, reads inside a transaction stay in the hostgroup where it started. Statements that must see their own writes need a rule that keeps them on hostgroup 1.

-- Did the monitor place the servers, and is traffic arriving?
SELECT hostname, port, read_only, error
FROM monitor.pgsql_server_read_only_log
ORDER BY time_start_us DESC LIMIT 6;

SELECT hostgroup, srv_host, status, ConnUsed, ConnFree, Queries
FROM stats_pgsql_connection_pool;

Interpretation: the primary should log read_only 0 and the replicas 1, with an empty error. In the pool stats, a rising Queries count in hostgroup 2 confirms the read rule is matching. If ConnUsed keeps climbing toward max_connections, something is pinning connections.

What changed for MySQL users between ProxySQL 2.7 and 3.0?

Less than the major version number suggests. The 3.0.1 notes call the MySQL module stable, and the mysql_servers, mysql_users, mysql_query_rules, and mysql_replication_hostgroups tables keep the shapes 2.x users know. What changes is packaging, OpenSSL handling, and a list of opt-in features. A few 3.0.12 behaviour changes can also affect existing rules.

The distribution list comes from the installation page, which marks RHEL 7 and 8, Debian 10 and 11, Ubuntu 16.04 to 20.04, and Amazon Linux 2 as "ProxySQL v2.7.x and older releases only". The MySQL features added across 3.0.x are mostly opt-in:

• 3.0.1: dual passwords, prepared-statement parameter logging (mysql-eventslog_stmt_parameters, off by default), and SHOW REPLICA STATUS for MySQL newer than 8.0.23.
• 3.0.2: Group Replication support for MySQL 8.4 and 9.x.
• 3.0.7 and 3.0.8: zstd protocol compression, with mysql-zstd_compression_level defaulting to 3, and mysql-session_track_system_variables (default DISABLED).
• 3.0.10: per-hostgroup query timeouts and AWS RDS Blue/Green monitoring. LOAD ... VARIABLES TO RUNTIME now reports rejected and unknown variables.
• 3.0.11: mysql-user_variable_tracking and mysql-update_gtid_from_ok, both off by default.
• 3.0.12: CIDR prefixes in client_addr and proxy_addr query-rule conditions, and MariaDB GTIDs for causal reads.

Authentication changes for MySQL 8.4 accounts are covered in our separate post on MySQL 8.4 authentication errors and caching_sha2_password.

-- ProxySQL admin, port 6032: list rules that rely on regular expressions
SELECT rule_id, match_digest, match_pattern, negate_match_pattern, destination_hostgroup
FROM mysql_query_rules
WHERE active = 1 AND (match_digest IS NOT NULL OR match_pattern IS NOT NULL)
ORDER BY rule_id;

Interpretation: the 3.0.12 upgrade notes say recursive regex matching now has a limit, and "a rule that reaches a match or recursion limit is skipped, including a negated rule". Review long or nested patterns, especially negated ones, and test them against your real digests on staging.

How do you upgrade a ProxySQL node from 2.7 to 3.0?

Treat it as a package swap with a backup, one node at a time, behind a load balancer or DNS name that can drain the node. The installation guide describes it: stop ProxySQL, take a raw copy of the executable, configuration, plugins, and /var/lib/proxysql/proxysql.db, install, then start and verify. Its rollback advice is direct: "do not assume a database written by a newer version is backward compatible."

# Before the window: save what runtime looks like now (contains credentials)
mysql -u admin -p -h 127.0.0.1 -P 6032 -e "
  SELECT * FROM runtime_mysql_servers;
  SELECT * FROM runtime_mysql_query_rules;
  SELECT * FROM runtime_mysql_users;" > /root/proxysql-runtime-2.7.txt
chmod 600 /root/proxysql-runtime-2.7.txt

Interpretation: you compare this file with the same queries after the upgrade. Keep it on the host or in a secrets store, because runtime_mysql_users includes password hashes.

# Debian or Ubuntu, as root: point APT at the 3.0 series (commands from the ProxySQL install guide)
wget -nv -O /etc/apt/trusted.gpg.d/proxysql-3.0.x-keyring.gpg \
  'https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/repo_pub_key.gpg'
echo deb https://repo.proxysql.com/ProxySQL/proxysql-3.0.x/$(lsb_release -sc)/ ./ \
  | tee /etc/apt/sources.list.d/proxysql.list
apt-get update
apt-cache policy proxysql

Interpretation: the candidate version should now be a 3.0.x build. If it still shows 2.7.x, the old source file is still active. On RHEL-family systems, change proxysql-2.7.x to proxysql-3.0.x in the baseurl and gpgkey lines of /etc/yum.repos.d/proxysql.repo.

# Rollback on Debian or Ubuntu, as root, after restoring the 2.7.x APT source
systemctl stop proxysql
apt-get update
apt-cache policy proxysql            # note the exact 2.7.4 package version
apt-get install --allow-downgrades proxysql=<2.7.4 package version>
cp -a /var/lib/proxysql/proxysql.db.pre-3.0 /var/lib/proxysql/proxysql.db
systemctl start proxysql

Interpretation: after the restart, proxysql --version should report 2.7.4 and the runtime tables should match your 2.7 capture. Changes made on 3.0 after the backup are lost, which is why configuration stays frozen until every node is done.

How do you upgrade a ProxySQL Cluster without config drift?

ProxySQL Cluster is pull-based. Each node compares configuration checksums with its peers. After a mismatch persists for admin-cluster_*_diffs_before_sync checks (default 3), it pulls the module from the peer and, with the default save_to_disk settings, saves it locally. We found no ProxySQL statement on running mixed 2.7 and 3.0 nodes in one cluster, so keep the mixed period short and make no configuration changes during it. With no new LOAD ... TO RUNTIME, no node has a newer version to pull.

-- Run on each node before the rollout and after each node is upgraded
SELECT hostname, port, name, version, epoch, diff_check
FROM stats_proxysql_servers_checksums
WHERE name IN ('mysql_servers', 'mysql_users', 'mysql_query_rules', 'mysql_variables')
ORDER BY name, hostname;

Interpretation: diff_check counts consecutive checks where a peer's configuration differed. If it climbs on any module while you are mid-rollout, stop and find out which node changed before more nodes pull from it. PostgreSQL modules (pgsql_servers, pgsql_users, pgsql_query_rules, pgsql_variables) sync only between nodes on 3.0.8 or later, so add PostgreSQL configuration after the whole cluster runs 3.0.12.

ProxySQL vs PgBouncer vs Pgpool-II: which fits PostgreSQL?

They solve overlapping but different problems. PgBouncer is a lightweight pooler. Pgpool-II adds load balancing, failover, and its own HA layer. ProxySQL routes by query rule and serves MySQL and PostgreSQL from one layer. The table uses each project's own documentation as of November 2026.

Sources: the PgBouncer changelog and features page, the Pgpool-II 4.7 introduction, and ProxySQL's PostgreSQL failover primer, which states plainly that ProxySQL "does not promote".

• Choose PgBouncer when you only need to cut connection counts, especially with transaction pooling. PgBouncer 1.26 also tracks search_path on PostgreSQL 18 and default_transaction_read_only on PostgreSQL 14 and above by default.
• Choose Pgpool-II when you want the proxy itself to run failover and you are prepared to operate its watchdog. Pgpool-II recommends at least three nodes to avoid split brain.
• Choose ProxySQL when you need rule-based routing, query digests, or one proxy layer for MySQL and PostgreSQL, and you already have Patroni, repmgr, or a managed service for promotion.

Some teams chain them. The 3.0.9 notes fix a startup options bug that broke client → ProxySQL → PgBouncer → PostgreSQL setups, so that layout is in real use. Each extra hop adds latency and another place where session state must be right, so measure it first.

Frequently asked questions

Key takeaways

Planning a ProxySQL 3.0 upgrade with JusDB

JusDB's ProxySQL engineers can review your current 2.x configuration and query rules, check which nodes need an OS change first, and plan a node-by-node upgrade with a tested rollback. For PostgreSQL, we can help you compare ProxySQL with PgBouncer or Pgpool-II against your own traffic before you change the connection path.

See our ProxySQL architecture and query routing page for the patterns we work with.

Related reading

• ProxySQL query routing: read/write splitting and connection pooling
• Database connection management at scale: PgBouncer and ProxySQL patterns
• PgBouncer connection pooling: transaction mode setup and tuning
• Vendor documentation: ProxySQL PostgreSQL documentation