Merge pull request #232091 from AwdotiaRomanowna/patch-27

Update concepts-limits.md

Author: prmerger-automator[bot]

articles/postgresql/flexible-server/concepts-limits.md

@@ -45,10 +45,10 @@ The maximum number of connections per pricing tier and vCores are shown below. T
 When connections exceed the limit, you may receive the following error:
 > FATAL:  sorry, too many clients already.
 
-> [!IMPORTANT]
-> For best experience, it is recommended to you use a connection pool manager like PgBouncer to efficiently manage connections. Azure Database for PostgreSQL - Flexible Server offers pgBouncer as [built-in connection pool management solution](concepts-pgbouncer.md). 
+> [!CAUTION]
+> While the maximum number of connections for certain SKUs is high, it's not recommended to set the max_connections parameter value to it's maximum. This is because although it may be a safe value when most connections are in the idle state, it can cause serious performance issues once they become active.  Instead, if you require more connections, we recommend using pgBouncer, Azure's built-in connection pool management solution, in transaction mode. To start, use safe values by multiplying vCores in the range of 2 to 5, and then check the resource utilization and application performance to ensure everything is running smoothly. For more information on pgBouncer, refer to the [PgBouncer in Azure Database for PostgreSQL - Flexible Server](concepts-pgbouncer.md) documentation.
 
-A PostgreSQL connection, even idle, can occupy about 10 MB of memory. Also, creating new connections takes time. Most applications request many short-lived connections, which compounds this situation. The result is fewer resources available for your actual workload leading to decreased performance. Connection pooling can be used to decrease idle connections and reuse existing connections. To learn more, visit our [blog post](https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/not-all-postgres-connection-pooling-is-equal/ba-p/825717).
+When using PostgreSQL for a busy database with a large number of concurrent connections, there may be a significant strain on resources. This strain can result in high CPU utilization, particularly when many connections are established simultaneously and when connections have short durations (less than 60 seconds). These factors can negatively impact overall database performance by increasing the time spent on processing connections and disconnections. It's important to note that each connection in Postgres, regardless of whether it is idle or active, consumes a significant amount of resources from your database. This can lead to performance issues beyond high CPU utilization, such as disk and lock contention, which are discussed in more detail in the PostgreSQL Wiki article on the [Number of Database Connections](https://wiki.postgresql.org/wiki/Number_Of_Database_Connections). To learn more about identifying and solving connection performance issues in Azure Postgres, visit our [blog post](https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/identify-and-solve-connection-performance-in-azure-postgres/ba-p/3698375).
 
 ## Functional limitations