Important Gotchas and Limitations About Azure Database for PostgreSQL

Azure Database for PostgreSQL (called Azure PG, henceforth) is a fully managed service provided by Microsoft. Azure PG provides features like push-button scalability, high availability, automated geo distributed backups, encryption at rest, point in time restore (PITR) which makes it highly desirable if you use PostgreSQL and Azure is your platform of choice. It’s a competing service for Amazon RDS for PostgreSQL.

However, like any other decision in computing, there are certain tradeoffs that one needs to be aware of while choosing a service. Here are certain gotchas and limitations you should be aware of while choosing Azure PG.

• Automatic major version upgrade is not supported.

Azure PG supports automatic upgrades for minor version patches. However, upgrading from a major version like PostgreSQL 9.5 to PostgreSQL 9.6 is not supported.

• Major versions supported.

As of Feb. 2019, only PostgreSQL versions 9.5, 9.6 and 10 are supported with Azure PG. PostgreSQL 11 support is noticeably missing. PG 11 is available on Amazon RDS.

• You can change the storage and backup retention period without any downtime, but you can’t change the backup type once the server is created. You can choose between locally redundant and geo-redundant backups.

• The storage can only be increased.

• When restoring a server using PITR, the new server created doesn’t have the firewall rules which were added to the original server. You will need to add these again. You might also need to recreate the database level logins and permissions.
• Once you reach the 95% limit of the allocated storage, the server shifts to read-only mode.

• You can not upgrade to General Purpose or Memory Optimized instance types from Basic instance type. Basic instance is limited to max 2 vCores and 4GB of RAM.

• Maximum storage size for Basic instance type is 1 TB. Maximum storage for General Purpose and Memory Optimized instances is 4 TB.

• VNet is supported for only General Purpose or Memory Optimized instances.

• When you change the number of vCores, instance type or pricing tier, a copy of the existing server is created with new capacity. Then connections are switched over to the new instance. There can be a service disruption of up to a minute during this switchover.

• You can configure up to 5 read replicas in same Azure region for a master Azure PG database.

• You can disconnect a read replica from the master DB. Once disconnected the read replica becomes a standalone DB. Once converted to standalone DB it can be converted to a read replica again.

• When a master DB server is deleted, all of its replicas become standalone servers.

Despite all of these limitations, Azure PgSQL is a very good service. All managed DB services have limitations on one type or another. As a cloud specialist, it’s very important to know these limitations beforehand so as to ensure that a production deployment doesn’t run into one of these unexpected.

At Mobisoft, we ensure that our Cloud Developers are aware of such nuances for each of the cloud platforms we use. Are you in need of such Cloud Experts? Please get in touch and we will be happy to guide you!

Author's Bio:

Pritam Barhate