Recent ProxySQL updates: 3.0.7, Orchestrator, PostgreSQL HA, dbdeployer, and more

[René Cannaò]

Hi everyone,

Since my last update, we have published several new blog posts on proxysql.com. There has been a lot of activity, so I wanted to share a grouped summary rather than just a list of links.

First, we released ProxySQL 3.0.7, 3.1.7, and 4.0.7 across our release tiers. This release cycle focuses on security hardening, zstd compression support for the MySQL protocol, and new TLS observability tables:

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

We also published deeper technical posts covering the main 3.0.7 improvements:

Security hardening in ProxySQL 3.0.7
https://proxysql.com/blog/proxysql-3-0-7-security-hardening

zstd compression support in ProxySQL 3.0.7
https://proxysql.com/blog/proxysql-3-0-7-zstd-compression

New observability tables for TLS certificate tracking
https://proxysql.com/blog/proxysql-3-0-7-new-tls-tables

Together, these posts explain why 3.0.7 is an important production upgrade: stronger protocol validation, better protection around administrative credentials, more efficient compression for supported MySQL clients, and better visibility into TLS certificate status directly from the ProxySQL admin interface.

We also made an important open-source announcement: ProxySQL is taking over the maintenance and development of Orchestrator.

https://proxysql.com/blog/announcing-proxysql-takes-over-orchestrator

Orchestrator has been a key tool in the MySQL high-availability ecosystem for many years. We believe ProxySQL and Orchestrator are naturally complementary: Orchestrator understands topology and recovery, while ProxySQL controls traffic routing and application-facing availability. Bringing the two projects closer together opens the door to a more integrated HA experience.

On the PostgreSQL side, we started a new technical series about how ProxySQL fits into PostgreSQL failover architectures. The goal of the series is to be precise about what ProxySQL does, what it does not do, and how it changes the application-side behavior during failover.

The primer introduces the failover model and vocabulary:

https://proxysql.com/blog/proxysql-postgresql-failover-primer

The second post walks through an unplanned primary failure and explains how ProxySQL can reduce the gap between database promotion and successful application writes:

https://proxysql.com/blog/proxysql-postgresql-unplanned-primary-failure

We also published a post about Orchestrator for PostgreSQL, showing how our Orchestrator work extends beyond MySQL and how it can participate in PostgreSQL topology discovery and failover workflows:

https://proxysql.com/blog/orchestrator-postgresql-intro

We continued the dbdeployer series as well. After ProxySQL took over dbdeployer maintenance, our goal has been to evolve it from a MySQL-only sandbox tool into a broader database infrastructure tool.

What’s coming to dbdeployer
https://proxysql.com/blog/proxysql-dbdeployer-whats-coming

The Provider Architecture — how dbdeployer learned to speak PostgreSQL
https://proxysql.com/blog/dbdeployer-provider-architecture

These posts explain the direction of the project, including PostgreSQL support and the new provider architecture that makes dbdeployer more extensible.

Finally, Rahim published a detailed technical post on ProxySQL’s PostgreSQL prepared statement cache refactor:

https://proxysql.com/blog/proxysql-3-0-4-prepared-statement-cache-refactor

This post explains how a contended global-lock path was redesigned, improving prepared statement performance for PostgreSQL workloads under concurrency.

If you are following ProxySQL from the MySQL side, I recommend reading the 3.0.7 release/security/compression/TLS posts and the Orchestrator announcement.

If you are following our PostgreSQL work, I recommend reading the PostgreSQL failover series, the Orchestrator for PostgreSQL post, and the prepared statement cache refactor.

And if you care about development, testing, sandboxes, or reproducible database environments, the dbdeployer posts are worth reading.

As always, feedback is very welcome.

Best,
René