ProxySQL

A high-performance L7 proxy for MySQL and PostgreSQL protocols . 100% open source. Contact us for 24/7 Support, DBRE, Consulting & more!

[ProxySQL @proxysql]

ProxySQL 2.7.4 is out: security and severe bug fixes for the 2.7 LTS series. No new features.

Running an earlier 2.7 release? Prioritize this update.

https://t.co/Z0UosY4PLH

[ProxySQL @proxysql]

Our ProxySQL scheduling work includes testing what happens around the queue:

• Backend capacity runs out
• Waiting clients disconnect
• Requests time out
• Connections become available again

We’re combining those behavior checks with runtime measurements and examining how idle connections and worker assignment interact with the scheduler.

Which pool-contention scenario would you like us to walk through next?

[ProxySQL @proxysql]

Connected clients and active work are different things.

ProxySQL already supports dedicated idle threads so idle connections can move away from active workers until needed.

Our scheduling work also improves worker-load estimates by counting sessions queued to resume, alongside active sessions.

That gives session placement a more complete picture of the work already heading toward each worker.

[ProxySQL @proxysql]

Need a local MariaDB replication environment to reproduce a problem?

Our dbdeployer update walks through downloading MariaDB 12.3.3, unpacking it, deploying a three-node replication sandbox, and running its replication test.

It also covers Galera, PostgreSQL, and adding ProxySQL to supported topologies with --with-proxysql.

Use a compatible host with the database runtime dependencies installed. The article includes prerequisites and links to the detailed guides.

Try the examples with dbdeployer v2.4.2:
https://t.co/usO6OWmkXi

#dbdeployer #DatabaseTesting

[ProxySQL @proxysql]

Putting requests in a queue is only part of connection-pool scheduling.

While a request waits, its client can disconnect, its timeout can expire, or its session can be terminated.

Our ProxySQL work handles those transitions explicitly—even behind a blocked queue head.

Waiting sessions are tracked separately, but remain subject to disconnect, timeout, and termination handling. A queue needs a reliable exit path.

[ProxySQL @proxysql]

A configuration change needs a return path: evidence of what each proxy replica is actually running.

The reconcile loop in our MySQL BR Conf presentation follows the change from a desired-state version, through the in-cluster agent and Kubernetes objects, to the operator applying it across the ProxySQL fleet.

Applied versions and per-replica sync status come back to the console. Runtime capture and drift reporting help expose differences between intended and running configuration.

The diagram and operational walkthrough are in the article, with the complete PDF:
https://t.co/nCek21ZnkD

#ProxySQL #BYOC

[ProxySQL @proxysql]

The dbdeployer update also covers PostgreSQL work from v2.4.0 and v2.4.1:

• Corrected Debian package extraction and shared-file layout.
• Fixes for port collisions across sandbox deployments.
• Waiting for replicas to accept queries before deployment returns.
• A generated test_replication script to verify data flow.
• Placement and credential options for deploy postgresql.

Useful improvements when you're running several local environments or automating a test setup.

Examples and the broader release story:
https://t.co/usO6OWlN7K

#PostgreSQL #dbdeployer

[ProxySQL @proxysql]

A connection pool has a dependency built into it: waiting requests need connections that other sessions are still using.

That’s why processing order matters.

In ProxySQL’s updated scheduler, sessions holding backend connections run first. Queued requests then get another opportunity to acquire capacity before other work starts.

The design follows the resource lifecycle: let work progress, release connections, revisit the queue.

[ProxySQL @proxysql]

A replica can pass its health checks and still be missing the write a confirmation read needs.

The MySQL GTID example in our @nerdearla slides makes that dependency explicit: track the successful write, then consider readers whose executed transaction set includes it.

That supplies evidence for the read's freshness requirement. The routing policy still needs a deadline and a fallback when no reader is ready, alongside the application's session and transaction requirements.

Mechanism, diagrams, and the full presentation:
https://t.co/3wPLBN6ivz

#MySQL #ProxySQL

[ProxySQL @proxysql]

What happens when every backend connection is busy?

The next request waits. How the proxy manages that wait matters.

We’ve implemented connection-pool scheduling changes in ProxySQL’s 3.1 and 4.0 builds for MySQL and PostgreSQL: organize waiting sessions by hostgroup, process sessions already holding connections first, then retry queued requests.

The goal: help work keep moving when backend capacity is limited.

[ProxySQL @proxysql]

In dbdeployer v2.4.2, a Galera/PXC node that fails to become ready within 120 seconds stops the deployment with an error identifying the node and its log.

Joining nodes now use the appropriate sandbox credentials for the readiness check. Previously, authentication could fail and the check would silently time out, letting deployment continue.

Ordinary MariaDB sandboxes skip the Galera wait entirely.

The result: less unnecessary waiting and clearer failures when a cluster cannot become ready.

Details and MariaDB examples:
https://t.co/usO6OWlN7K

#MariaDB #Galera

[ProxySQL @proxysql]

The final slides from @rene_cannao and @ask_dba's MySQL BR Conf session are available: “Managed ProxySQL, in Your Own AWS Account.”

The BYOC architecture puts the proxy cluster inside the customer's AWS account and VPC, with a separate management control plane and an outbound agent connection.

The follow-up explains that boundary, then walks through discovery, configuration reconciliation, upgrades, observability, and a staged rollout.

Read the article and download the complete 43-slide PDF:
https://t.co/nCek21YPv5

#ProxySQL #MySQL #BYOC

[ProxySQL @proxysql]

“SQL Traffic Routing Without Breaking Consistency” : the full Nerdearla presentation is available.

@rene_cannao uses a ticket-booking application to connect pooling, session state, replica freshness, and failover.

A catalog query and a booking confirmation may both be SELECTs, but they can need different routing policies. One may tolerate stale data; the other needs to see the booking that just committed.

The technical follow-up covers those requirements, MySQL GTID-based routing, and measuring traffic before moving it.

Walkthrough + downloadable 50-slide PDF:
https://t.co/3wPLBN6ivz

#ProxySQL #MySQL

[ProxySQL @proxysql]

São Paulo, the MySQL community, and the ProxySQL team together.

At MySQL BR Conf 2026, @rene_cannao and @ask_dba presented “Managed ProxySQL, in Your Own AWS Account.”

The focus was operating the proxy fleet: configuration, upgrades, monitoring, and the boundary between a management service and the infrastructure serving application traffic inside the customer's AWS account.

@JesmarCannao , @ask_dba , and @rene_cannao also got together for a team photo.
The MySQL dolphins joined in.

Thanks to the organizers, university hosts, volunteers, and everyone who took part.

Our recap from Brazil:
https://t.co/aaJoxhcLpw

#MySQL #ProxySQL

[ProxySQL @proxysql]

The booking is committed. The confirmation read goes to a replica. The ticket appears to be missing.

SQL routing decisions become application behavior.

At @nerdearla 2026 in Buenos Aires, @rene_cannao presented “SQL Traffic Routing Without Breaking Consistency,” using a ticket-booking example to connect pooling, transactions, replication, and failover.

A replica can be healthy and still be the wrong destination for a particular read. The application's requirements have to guide the routing policy.

Thanks to the @nerdearla organizers, volunteers, and everyone who joined the session at Konex or online.

Our Buenos Aires recap:
https://t.co/Z8XH1DaK8S

#Nerdearla #ProxySQL

[ProxySQL @proxysql]

dbdeployer v2.4.2 is out.

A three-node MariaDB replication deployment reported at roughly 8 minutes now takes about 20 seconds after fixing an unnecessary readiness wait. Actual times depend on the environment.

This release also fixes readiness checks for joining Galera/PXC nodes and expands MariaDB CI coverage.

Our new blog goes beyond the release: MariaDB downloads, PostgreSQL improvements, cluster testing, and the work since April to make local database sandboxes more reliable.

If you're using v2.4.0 or v2.4.1 for MariaDB, take a look:
https://t.co/usO6OWlN7K

#dbdeployer #MariaDB

[ProxySQL @proxysql]

AI plumbing has to behave like production infrastructure.
ProxySQL 4.0.11 makes MCP/GenAI defaults, authenticated readiness checks, runtime reloads, TSDB access and plugin shutdown more predictable.

https://t.co/VbfvBU6zet

[ProxySQL @proxysql]

Fast Forward traffic should not be a blind spot.

ProxySQL 3.1.11 improves FFTO accounting for modern MySQL result flows and pipelined PostgreSQL queries, while TSDB synchronization avoids transient-lock failures.

https://t.co/UOsAdulS6A

#MySQL #PostgreSQL #Observability

[ProxySQL @proxysql]

ProxySQL 3.1.11 adds modern, opt-in authentication:
- MySQL caching_sha2_password RSA exchange
- MariaDB ed25519
- per-user X.509 requirements.

TLS remains the recommendation for full-session confidentiality.

https://t.co/UOsAdulS6A

[ProxySQL @proxysql]

A ProxySQL fleet spanning clouds and regions is hard to see. In Amsterdam, we showed how https://t.co/ForbkiP7nL brings health, traffic, configuration, backups, and alerts into one control plane.

https://t.co/4ZJ0mMcQ8M