MySQL BR Conf 2026 Slides: Managed ProxySQL in Your Own AWS Account
Hero photo: the MySQL BR Conf community at Universidade Anhembi Morumbi in São Paulo. Photo: @alefotografo, shared in Guilherme Duarte de Barros’s event album.
The final slides from Managed ProxySQL, in Your Own AWS Account, the talk Alkin Tezuysal and I presented at MySQL BR Conf 2026, are available below.
Download the final presentation (PDF, 43 slides).
The session focused on the BYOC architecture and the operating model around the proxy fleet. Here is a closer look at the main ideas.
The proxy tier needs an operating model
ProxySQL sits between applications and databases, providing connection pooling, routing, and visibility into SQL traffic. Running a fleet of proxies also creates work: keeping configuration consistent, handling upgrades, maintaining monitoring, and tracking changes made during an incident.
Those tasks become especially important when every application query passes through the tier being changed.
The ProxySQL.Cloud model presented in the session separates the management service from the infrastructure that serves application traffic. BYOC means bringing your own cloud account: the ProxySQL cluster runs in your AWS account and VPC, alongside the network paths to your applications and databases.
Two planes, with an explicit boundary
The architecture has two main parts:
- The control plane, in the service provider’s account, holds desired state and exposes the management console and API, aggregated metrics, and management history.
- The data plane, in the customer’s account, contains the ProxySQL cluster and its local management components. Application SQL traffic travels through that cluster to the databases inside the customer’s network.
An in-cluster agent initiates an outbound HTTPS connection to the control plane. The model does not require opening an inbound management port, VPN, or peering connection to it.
The slides distinguish management information that crosses the boundary — configuration intent, lifecycle status, aggregated metrics, query digests, and audit events — from row data, database credentials, application secrets, and query text containing literals, which remain in the customer environment. Proxy configuration backups go to the customer’s own S3 bucket.
The observability section also describes requesting pod logs through the console. That on-demand path belongs in a review of the data flows, alongside the routine telemetry. A useful boundary description needs to account for operational workflows as well as the normal query path.
If the control plane becomes unreachable, the proxies continue serving using their existing state. Management pauses. This separation keeps a management connectivity problem from automatically becoming an interruption to SQL traffic; it does not remove the data plane’s own infrastructure dependencies.
Desired configuration becomes running configuration
The workflow begins with the customer providing the AWS environment, Kubernetes cluster, network access to the databases, and a scoped IAM role for the agent.
Discovery uses a reachable backend and a read-only user to inspect the topology. It produces a proposed configuration for review, including hostgroups and monitor settings. Routing intent still comes from the application team: discovering a replica does not establish which application reads can safely use it.
After a configuration change is accepted, the control plane records a new desired-state version. The agent retrieves it and writes Kubernetes objects; the operator brings the ProxySQL replicas into line with that state and reports their progress.
This gives an operator two distinct things to inspect: what the cluster should be running and what each replica is actually running. Configuration history, runtime capture, diffs, and drift reporting make that distinction visible.
The presentation also covers importing an existing configuration and exporting it again, so a rollout can begin from the configuration a team already understands.
Day-to-day operations need controlled changes
Several examples in the deck follow the same pattern: make the intended change explicit, constrain how it is applied, and record what happened.
Upgrades proceed one proxy replica at a time, with health checks gating progress. Autoscaling works within customer-defined bounds and uses cooldowns between decisions. Maintenance workflows include draining a backend before working on it, while configuration history provides a path back to an earlier version.
Managed application credentials cover both sides of authentication: what the application presents to the proxy and what the proxy uses to connect downstream. Those credentials remain in the customer account under the model described in the slides.
The backup scope is also specific: proxy configuration and its history, not database contents. Database backups remain part of the existing database recovery strategy. Testing a proxy configuration restore complements that strategy; it does not replace it.
For observability, the deck brings together connection counts, backend pool usage, query digests, and an activity history. The dashboard numbers shown in the presentation are demo values, not performance benchmarks or service guarantees.
Start with one service
The adoption sequence begins with connecting the environment and reviewing discovery before any application traffic moves. The next step is a limited rollout with one service, comparing latency and errors with its existing path. Further services and policies can follow once that behavior is understood.
That sequence makes the first decision concrete: can this proxy configuration serve this application’s workload correctly and reliably? Fleet-wide changes can wait until there is evidence from a smaller deployment.
Read the final slides for the architecture diagrams, responsibility split, and console walkthrough. To discuss the model for your environment, see ProxySQL’s managed service.