Azure PostgreSQL Managed DB: Scaling Query

Hi **Harsh,
**I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Hi,

Thank you for the detailed response.

We are currently looking into all three recommendations. PgBouncer connection pooling and read replicas are on our roadmap, and we have Azure Monitor alerts in place for CPU thresholds. We will be implementing these progressively as we scale.

Thanks again for the guidance.

Hi Harsh,

Thanks for the update — you’re taking the right approach. As you scale toward 40+ application servers, the biggest risk isn’t just higher traffic, but the growth in concurrent connections and connection churn, which can drive CPU high and lead to timeouts even when queries aren’t individually heavy.

1) Prioritize PgBouncer early (connection pooling). With many app instances, opening/maintaining lots of direct PostgreSQL connections is expensive. PgBouncer reduces overhead by reusing a smaller pool of backend connections, which often stabilizes CPU and improves resilience during bursts. If you use the built‑in PgBouncer option in Flexible Server, you can point your apps to the PgBouncer endpoint (commonly via port 6432) while PostgreSQL remains on 5432.
2) Add read replicas when reads start dominating. If your workload includes reporting, dashboards, or read-heavy APIs, read replicas are a clean way to scale reads without constantly scaling up the primary. This reduces CPU pressure on the primary and helps keep write performance stable.

3) Use Azure Monitor alerts as your “early-warning + scale trigger.” Since compute scaling is manual on Flexible Server, alerts are how you stay ahead of impact. Set alerts not only for CPU, but also for connection pressure and (if using PgBouncer) waiting/pooled connection indicators. Microsoft also supports multi-resource metric alert rules, which helps once you have one server per country/region.

4) Plan manual compute scaling for sustained trends (not one-off spikes). Flexible Server compute changes require manual action, and the server may briefly restart during the operation. A good pattern is: use pooling + replicas to absorb growth, and scale compute when metrics show sustained CPU/connection pressure rather than short bursts.

In short, the most efficient way to scale to 40+ application servers on Azure PostgreSQL Flexible Server is to reduce connection overhead with PgBouncer, offload reads using read replicas, and use Azure Monitor alerts to trigger planned manual scale-ups before users see timeouts. This combination keeps the primary stable and lets you grow predictably without relying on automatic compute scaling.
Microsoft Reference links

• Connection pooling best practices (PgBouncer): https://learn.microsoft.com/en-us/azure/postgresql/connectivity/concepts-connection-pooling-best-practices [Connection...soft Learn | Learn.Microsoft.com]
• Monitoring & metrics (includes PgBouncer metrics details): https://learn.microsoft.com/en-us/azure/postgresql/monitor/monitoring-metrics [Monitoring...soft Learn | Learn.Microsoft.com]
• Configure alerts for PostgreSQL Flexible Server: https://learn.microsoft.com/en-us/azure/postgresql/monitor/how-to-alert-on-metrics [Configure...soft Learn | Learn.Microsoft.com]
• Scale compute (how-to): https://learn.microsoft.com/en-us/azure/postgresql/scale/how-to-scale-compute
• Scaling resources (concepts): https://learn.microsoft.com/en-us/azure/postgresql/scale/concepts-scaling-resources
• Service limits (connections and other limits): https://learn.microsoft.com/en-us/azure/postgresql/configure-maintain/concepts-limits

Hi Harsh,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.