ProxySQL 3.0.8 and a new PostgreSQL proxy series

[René Cannaò]

Hi everyone,

Since the last update, we published three new posts on proxysql.com that I wanted to share with the mailing list.

First, we announced ProxySQL 3.0.8, together with 3.1.8 and 4.0.8:

https://proxysql.com/blog/announcing-proxysql-3-0-8

ProxySQL 3.0.8 is an important maintenance and feature release. It includes MySQL session-variable tracking, PostgreSQL Cluster Sync, per-server PostgreSQL backend SSL configuration, PostgreSQL mid-transaction backend-death recovery, PostgreSQL backend SSL keylog support, and several build and packaging improvements.

We also started a new series comparing PgBouncer and ProxySQL for PostgreSQL workloads.

Part 1 looks at the PostgreSQL middle tier from an architectural point of view:

https://proxysql.com/blog/part-1-pgbouncer-to-proxysql

PgBouncer is excellent when the main requirement is connection pooling. But as PostgreSQL deployments grow, the middle tier often becomes more complex: connection pooling in one place, routing logic in the application, HAProxy or another load balancer for failover-aware routing, exporters for metrics, and custom scripts for operational control.

The post explains where ProxySQL fits when the middle tier needs to do more than pooling: routing, topology awareness, failover handling, observability, and traffic policy.

Part 2 provides a more direct feature comparison:

https://proxysql.com/blog/part-2-pgbouncer-to-proxysql

It compares PgBouncer and ProxySQL across areas such as pooling behavior, read/write splitting, topology awareness, backend monitoring, replication lag handling, retries, query rules, observability, TLS configuration, audit/event logging, and runtime configuration.

The goal of the series is not to say that every PostgreSQL deployment should replace PgBouncer. PgBouncer remains a great tool when connection pooling is the main requirement.

The goal is to explain where ProxySQL becomes useful when PostgreSQL environments need a more capable database traffic layer.

If you are following our PostgreSQL work, I think these posts are worth reading together with the recent failover and Orchestrator posts. They show the direction we are taking: ProxySQL as a database proxy layer for both MySQL and PostgreSQL, with routing, observability, failover support, and operational controls in one place.

As always, feedback is very welcome.

Best,

René