Limits in Azure Database for PostgreSQL - Single Server
APPLIES TO: 
Azure Database for PostgreSQL - Single Server
Important
Azure Database for PostgreSQL - Single Server is on the retirement path. We strongly recommend that you upgrade to Azure Database for PostgreSQL - Flexible Server. For more information about migrating to Azure Database for PostgreSQL - Flexible Server, see What's happening to Azure Database for PostgreSQL Single Server?.
The following sections describe capacity and functional limits in the database service. If you'd like to learn about resource (compute, memory, storage) tiers, see the pricing tiers article.
Maximum connections
The maximum number of connections per pricing tier and vCores are shown below. The Azure system requires five connections to monitor the Azure Database for PostgreSQL server.
| Pricing Tier | vCore(s) | Max Connections | Max User Connections |
|---|---|---|---|
| Basic | 1 | 55 | 50 |
| Basic | 2 | 105 | 100 |
| General Purpose | 2 | 150 | 145 |
| General Purpose | 4 | 250 | 245 |
| General Purpose | 8 | 480 | 475 |
| General Purpose | 16 | 950 | 945 |
| General Purpose | 32 | 1500 | 1495 |
| General Purpose | 64 | 1900 | 1895 |
| Memory Optimized | 2 | 300 | 295 |
| Memory Optimized | 4 | 500 | 495 |
| Memory Optimized | 8 | 960 | 955 |
| Memory Optimized | 16 | 1900 | 1895 |
| Memory Optimized | 32 | 1987 | 1982 |
When connections exceed the limit, you may receive the following error:
FATAL: sorry, too many clients already
Important
For best experience, we recommend that you use a connection pooler like pgBouncer to efficiently manage connections.
A PostgreSQL connection, even idle, can occupy up to 2MB 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. A connection pooler that decreases idle connections and reuses existing connections will help avoid this.
Functional limitations
Scale operations
- Dynamic scaling to and from the Basic pricing tiers is currently not supported.
- Decreasing server storage size is currently not supported.
Server version upgrades
- Automated migration between major database engine versions is currently not supported. If you would like to upgrade to the next major version, take a dump and restore it to a server that was created with the new engine version.
Note that prior to PostgreSQL version 10, the PostgreSQL versioning policy considered a major version upgrade to be an increase in the first or second number (for example, 9.5 to 9.6 was considered a major version upgrade). As of version 10, only a change in the first number is considered a major version upgrade (for example, 10.0 to 10.1 is a minor version upgrade, and 10 to 11 is a major version upgrade).
VNet service endpoints
- Support for VNet service endpoints is only for General Purpose and Memory Optimized servers.
Restoring a server
- When using the PITR feature, the new server is created with the same pricing tier configurations as the server it is based on.
- The new server created during a restore does not have the firewall rules that existed on the original server. Firewall rules need to be set up separately for this new server.
- Restoring a deleted server is not supported.
UTF-8 characters on Windows
- In some scenarios, UTF-8 characters are not supported fully in open source PostgreSQL on Windows, which affects Azure Database for PostgreSQL. Please see the thread on Bug #15476 in the postgresql-archive for more information.
GSS error
If you see an error related to GSS, you are likely using a newer client/driver version which Azure Postgres Single Server does not yet fully support. This error is known to affect JDBC driver versions 42.2.15 and 42.2.16.
- We plan to complete the update by the end of November. Consider using a working driver version in the meantime.
- Or, consider disabling the GSS request. Use a connection parameter like
gssEncMode=disable.
Storage size reduction
Storage size cannot be reduced. You have to create a new server with desired storage size, perform manual dump and restore and migrate your database(s) to the new server.