September 5, 2026 by Rene Cannao · Release
#proxysql-3-0 #proxysql-3-1 #proxysql-4-0 #mysql #postgresql #security #authentication #mcp #open-source

Announcing ProxySQL 3.0.11, 3.1.11, and 4.0.11

On August 27, we released ProxySQL 3.0.11, 3.1.11, and 4.0.11 across all three release tiers. Together, these releases make connection reuse safer, strengthen authentication, improve observability under Fast Forward traffic, and harden the operational lifecycle of the GenAI and MCP plugin stack.

Most maintenance fixes are transparent after upgrading. The two new 3.0 routing features—literal user-variable tracking and GTID learning from OK packets—are opt-in. Operators moving to 3.1.11 or 4.0.11 should also review credential-scope separation, existing require_x509 attributes, and authenticated MCP readiness checks before rollout.

ProxySQL 3.0.11 (Stable Tier)

ProxySQL 3.0.11 is a Stable-tier maintenance release focused on safer MySQL multiplexing, more dependable causal reads, stronger authentication handling, and predictable operation during shutdown and query-cache refreshes.

Literal MySQL user variables can remain multiplexable

Applications often attach request metadata to a session using simple assignments such as SET @request_id = 1234. Historically, ProxySQL handled user-variable activity conservatively by binding the session to a hostgroup. This protects correctness, but it also prevents connection reuse when the values are simple literals that ProxySQL could safely preserve.

The new opt-in mysql-user_variable_tracking mode records supported literal assignments after the backend accepts the complete SET statement. When a later query uses a different pooled backend connection, ProxySQL replays only the missing or changed values before forwarding the application query. A backend that already has the required state is preferred, avoiding unnecessary replay.

The feature is intentionally bounded. It supports strings, numbers, hexadecimal and bit literals, and NULL; expressions, functions, variable references, prepared statements, and mixed system/user-variable assignments retain the existing safe fallback. Tracking is disabled by default, and mode 1 requires either mysql-set_parser_algorithm=3 or mysql-query_processor_parser=1.

More complete GTID knowledge for causal reads

min_gtid routing depends on ProxySQL knowing which endpoints have executed a transaction. The binlog reader remains the primary source of that information, but a visibility gap can arise when the same MySQL endpoint appears in both writer and reader hostgroups.

With the new opt-in mysql-update_gtid_from_ok setting, ProxySQL can also learn a GTID returned in a successful backend OK packet. The GTID is associated with the hostname and port, making the information available across hostgroup entries for the same endpoint. ProxySQL does not infer GTIDs or enable session_track_gtids on behalf of an application; it uses only GTIDs that MySQL actually returns.

Authentication and credential hardening

This release closes several subtle authentication edge cases:

  • Native-password and caching_sha2_password comparisons now validate response lengths before fixed-width reads, preventing malformed packets from causing out-of-bounds access.
  • MySQL and PostgreSQL handshakes now obtain randomness from OpenSSL RAND_bytes and abort cleanly if the random source fails.
  • Monitor credentials work correctly when mysql-default_authentication_plugin=caching_sha2_password is selected.
  • MariaDB client_ed25519 is supported for backend connections when ProxySQL has the cleartext password required to authenticate upstream.

Safer shutdowns and smoother cache refreshes

The --idle-threads shutdown path now coordinates worker and idle-thread destruction through a registration-counted barrier, removing NULL-dereference and use-after-free risks during shutdown.

Soft-TTL query-cache refreshes now use a single-flight model. When concurrent clients cross the soft-TTL boundary together, one request refreshes the entry from the backend while the others continue receiving the still-valid cached value. This avoids a burst of identical refresh queries for both MySQL and PostgreSQL caches.

Compatibility, diagnostics, and portability

ProxySQL 3.0.11 also improves day-to-day operations:

  • Admin accepts session-scoped autocommit, NET_READ_TIMEOUT, and NET_WRITE_TIMEOUT assignments used by current MySQL connectors and mysqldump.
  • MySQL client connection attributes are retained and exposed as client.connect_attrs in stats_mysql_processlist.extended_info.
  • Fast Forward connections keep compression enabled when using a Unix-socket backend.
  • PostgreSQL kill operations close their temporary backend connection after pg_terminate_backend() completes.
  • Generic Linux tarballs now include the required OpenSSL runtime and use bin/proxysql as the supported launcher. The packages are smoke-tested across multiple distributions and on both amd64 and arm64.
  • FreeBSD file-descriptor accounting now uses the platform’s native interface.

ProxySQL 3.1.11 (Innovative Tier)

ProxySQL 3.1.11 includes every Stable-tier improvement in 3.0.11 and adds modern frontend authentication capabilities, stronger per-user certificate policy, more accurate Fast Forward Traffic Observer (FFTO) statistics, and a more reliable time-series metrics store.

RSA full authentication for caching_sha2_password

Non-TLS MySQL clients can now complete caching_sha2_password full authentication through the standard RSA exchange. This supports both clients that request ProxySQL’s public key with --get-server-public-key and clients that use a pinned --server-public-key-path.

Operators can use automatically generated RSA-2048 keys or provide validated key files. Key loading is atomic, and every authentication exchange retains one immutable key snapshot so an in-progress login cannot receive one public key and be decrypted with a different private key after rotation.

RSA protects the password exchange, not the rest of the session. TLS remains the recommended option when the complete connection must be confidential and authenticated.

MariaDB ed25519 and per-user X.509 policy

The Innovative tier adds frontend MariaDB client_ed25519 authentication for initial login and COM_CHANGE_USER. It also introduces the require_x509 user attribute, allowing selected mysql_users rows to require frontend TLS and a successfully verified client certificate in addition to their normal authentication method.

For example, {"require_x509": true} in a user’s attributes enables this policy. Review existing attributes before moving from 3.0.x to 3.1.11: Stable 3.0.x ignores this key, while the Innovative tier enforces it.

Independent Admin and application credentials

Admin/Stats identities now have their own credential scope instead of sharing one runtime map with frontend database users. The same username can therefore exist on the Admin port and in mysql_users with different passwords without one identity overwriting or removing the other.

More accurate FFTO and more reliable TSDB metrics

FFTO now understands modern MySQL result framing, multi-result responses, prepared-statement cursor fetches, and pipelined PostgreSQL completion. This improves query digest, latency, row, affected-row, and error statistics for Fast Forward sessions while leaving forwarded traffic unchanged.

TSDB ingestion, discovery, and downsampling now coordinate access to their shared SQLite connection. Transient SQLITE_BUSY conditions are handled as operational events instead of terminating ProxySQL, and hourly rollover no longer races with metric discovery or ingestion.

FFTO remains opt-in and can be enabled independently for MySQL and PostgreSQL with mysql-ffto_enabled and pgsql-ffto_enabled.

ProxySQL 4.0.11 (Plugin Chassis / AI Tier)

ProxySQL 4.0.11 includes all Stable and Innovative-tier changes and delivers a concentrated reliability update for the GenAI plugin, MCP endpoints, RAG and vector tooling, runtime configuration reloads, and the shared TSDB metrics store.

Complete defaults without resetting operator configuration

Fresh or partially upgraded plugin databases now receive every missing canonical mcp-* and genai-* setting. Existing operator values always win: startup seeding and runtime reloads fill gaps instead of replacing configured values. The update is transactional, preventing a failed seed from leaving a partially populated configuration.

mcp-enabled remains disabled by default. The new initialization behavior makes the setting available immediately, but never silently starts the listener.

Safer runtime reloads

LOAD MCP VARIABLES TO RUNTIME and LOAD GENAI VARIABLES TO RUNTIME now coordinate with active MCP, RAG, AI-tool, query-hook, Admin, and status work. Shared consumers are quiesced before dependencies are replaced, a complete variable snapshot is published, and work resumes only after the related components have been refreshed.

The listener is recreated only when a relevant setting—such as enablement, port, or TLS mode—actually changes.

Consistent MCP authentication and readiness checks

MCP tool calls, test clients, and readiness probes now follow the same bearer-token contract. An endpoint with an empty mcp-*_endpoint_auth value refuses requests and reports which setting must be configured. This is a fail-closed policy, not an anonymous mode.

External health checks must therefore provide the same bearer credentials required by the endpoint they probe. Operators should review endpoint authentication settings before enabling MCP and update readiness checks that previously assumed unauthenticated access.

Predictable plugin lifecycle and shared metrics

Plugin shutdown and unload now drain client threads before destroying their modules, and shared AI/RAG bridges are detached in an ordered sequence. This reduces the risk of active work observing stale or partially destroyed runtime state.

The 4.0 tier also receives the TSDB synchronization improvements from 3.1.11, which are especially important when MCP or GenAI metric-discovery requests run alongside continuous ingestion and downsampling.

Before you upgrade

We recommend reviewing these points before rollout:

  • Both mysql-user_variable_tracking and mysql-update_gtid_from_ok are disabled by default. Enable and validate them independently.
  • Use the packaged bin/proxysql launcher with generic Linux tarballs so the bundled OpenSSL library path is applied.
  • On 3.1.11 and 4.0.11, review mysql_users.attributes for require_x509 before loading users to runtime.
  • Validate RSA key ownership, permissions, and rotation procedures if you provide explicit key files.
  • On 4.0.11, verify every MCP endpoint’s bearer-token configuration and ensure readiness clients send the appropriate credentials.

As always, test the upgrade with your production configuration and application drivers before rolling it out broadly.

Ready to upgrade? Read the full release notes for ProxySQL 3.0.11, ProxySQL 3.1.11, and ProxySQL 4.0.11.