Cloud SQL autoscaling read pools reach general availability

Google announced general availability of autoscaling read pools for Cloud SQL Enterprise Plus on March 19. The announcement covers MySQL and PostgreSQL pools behind a single read endpoint, with scaling based on CPU usage or database connections.

Replica capacity becomes a managed pool

Google describes pools containing one to twenty nodes and a common configuration applied across them. The endpoint remains stable as nodes are added or removed, reducing the application-side work of maintaining a replica list.

This can help a read-heavy application handle variable demand. It does not answer which reads are safe to route away from the primary. A user checking the result of a just-completed write may have a different consistency requirement from a dashboard showing aggregate trends.

Connection behavior also matters. Google notes that existing connections continue on their current nodes when capacity is added, while new connections can be directed to new nodes. A pool of long-lived application connections therefore deserves attention during scaling tests.

Test demand and consistency together

Start by classifying queries into those requiring the primary and those permitted to use replicas. Make that distinction explicit in application code or data-access configuration.

Then replay a traffic increase while observing replica lag, connection counts, and latency. Verify that the chosen scaling signal responds to useful demand rather than an unrelated rise in idle connections.

Set minimum and maximum capacity from the service’s recovery and budget requirements. Autoscaling boundaries are operational decisions, not values to copy from a demonstration.

The launch removes some replica orchestration work. A successful adoption still needs a workload-specific read-routing policy and evidence that additional nodes improve user-visible latency within the intended consistency limits.