Limits in 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.
The maximum number of connections per pricing tier and vCores are as follows:
|Pricing Tier||vCore(s)||Max Connections|
When connections exceed the limit, you may receive the following error:
FATAL: sorry, too many clients already
The Azure system requires five connections to monitor the Azure Database for PostgreSQL server.
- 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.