ProxySQL 3.0.12, 3.1.12, and 4.0.12 are out

We’ve released ProxySQL 3.0.12, 3.1.12, and 4.0.12.

If you’re running the Stable tier, there’s an immediate reason to plan an upgrade: this release fixes eight published security issues, four rated high and four medium. It also corrects problems with retries, transactions, and prepared statements.

For those following our PostgreSQL and plugin work, there’s quite a bit more to explore. Applications can now fetch PostgreSQL results in smaller pieces and receive database notifications through ProxySQL. We’ve added experimental caching for prepared queries, along with new plugins for DuckDB and MySQL Router compatibility.

3.0.12 is the Stable release. The new features in 3.1.12 and 4.0.12 are available as published prereleases.

PostgreSQL connections carry more than queries

Consider an application reading a large result. It might fetch some rows, process them, then come back for more. PostgreSQL needs to remember where that execution stopped. It calls the object holding that execution a portal.

Or consider an application waiting for an event. PostgreSQL’s LISTEN and NOTIFY let it subscribe to a channel and receive a message when another session publishes something. The notification can arrive while the application isn’t running a query.

Both cases require the proxy to understand what is happening between requests. An apparently idle connection may still hold an unfinished read or an active subscription.

That is the reason behind the native PostgreSQL backend work in this release.

There are two connections involved: the application connects to ProxySQL, and ProxySQL connects to PostgreSQL. We’ve changed how ProxySQL handles that second connection. It can now speak the PostgreSQL protocol directly, rather than passing the conversation through PostgreSQL’s client library, libpq.

With that control, ProxySQL can keep track of an open portal, forward an arriving notification, and keep the right database connection attached to the application.

This is available in 3.1.12 and 4.0.12, and is enabled by default for new TCP backend connections. Applications continue using their normal PostgreSQL clients.

These features do use connections differently from short queries that finish immediately. A subscription or an unfinished portal keeps its database connection, which matters when deciding how many connections your deployment needs.

Preparing a query doesn’t save its answer

An application might repeatedly look up the same product label using a prepared statement. Preparing the query avoids repeating some preparation work, but the database still executes it each time.

The new prepared-query cache can save that answer and return it on a later matching request.

For example, you could allow a product label to be reused for five seconds. If another request asks for the same label during that interval, ProxySQL may answer from the cache.

There is a decision to make here: if someone changes the label in the database, the cached answer can still contain the old label until it expires or the cache is cleared. Updating the database does not automatically clear that answer.

That may be acceptable for a label or a list of countries. An inventory check may need to reach the database every time.

We’re introducing this as an experimental feature in 3.1.12 and 4.0.12. It supports specific MySQL and PostgreSQL prepared-query operations, using the existing query-cache rules and expiry settings. The release notes explain which requests qualify. Existing broad cache rules deserve a review too, because they may now cover prepared requests that previously went to the database.

Less work keeping routing rules up to date

Suppose an application runs across several containers. Instances come and go, and their IP addresses change, but they all belong to the same network.

You can now write one query rule for that network. For example, 10.20.0.0/16 covers addresses whose first two numbers are 10.20. A new application instance in that range is already covered by the rule.

This uses CIDR, the standard notation for network ranges, and works with both IPv4 and IPv6.

MariaDB deployments also gain another routing option. An application can write to a primary, immediately read from a replica, and get an older value because replication hasn’t caught up yet. ProxySQL can now use MariaDB transaction identifiers to choose a replica that has reached the required write. That requires transaction tracking and replica-progress information to be configured.

Both changes are included in Stable 3.0.12.

DuckDB inside ProxySQL, and a connection to InnoDB Cluster

The DuckDB plugin gives ProxySQL an embedded analytical database. Supported MySQL and PostgreSQL clients can connect and run DuckDB SQL against the same database inside the proxy process.

There’s no separate DuckDB server to start. You can keep the database in memory for temporary work or store it in a file so the data survives a restart.

The MySQL Router compatibility plugin addresses a different operational problem. An InnoDB Cluster already knows which servers belong to it and which member is primary. The plugin lets ProxySQL register with the cluster and use that information to maintain its configuration as the topology changes.

Applications can connect to writer and reader endpoints, or use an endpoint where ProxySQL applies query rules to decide where statements should go.

Both plugins require source installation in 4.0.12. They are not included in the downloadable packages; the bundled plugins are MySQLX and GenAI.

Upgrading

Alongside the new features, we’ve fixed a retry case that could have serious consequences: replaying a batch after the application had already received some results. If the backend connection then failed, repeating the whole batch could execute earlier statements twice. ProxySQL now reports that failure instead of replaying the partly answered batch.

There are also corrections to PostgreSQL transaction recovery and authentication, MySQL prepared statements, and malformed network-packet handling.

For 4.0.12, review your query-rule patterns because PCRE2 becomes the default regular-expression engine. Existing MySQLX settings also need migration. Those changes are covered in the upgrade notes.

Downloads and the full details are available here:

Stable 3.0.12 is also available from the package repositories and as Docker images for AMD64 and ARM64.