Mastering the Move: Migrating from Azure Database for PostgreSQL Single to Flexible Server

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

In 2018, Azure introduced the General Availability of Azure Database for PostgreSQL - Single Server, providing an open-source database platform service on Azure. Now, Azure offers Azure Database for PostgreSQL - Flexible Server, bringing significant improvements in availability, scalability, and performance. With the deprecation of Azure Database for PostgreSQL - Single Server set for March 28, 2025, and the halt of new instance creation via the Azure portal starting November 30, 2023, it is crucial to migrate existing deployments. However, it's important to note that Azure Database for PostgreSQL - Single Server instances can still be created using the Azure Command Line Interface (CLI), even after the portal option becomes unavailable. 

This article guides you through considerations, approaches, and best practices for migrating from Azure Database for PostgreSQL - Single to Flexible Server, ensuring a seamless transition.

Migration Considerations

Before initiating the migration from Azure Database for PostgreSQL – Single Server to Flexible Server, it is crucial to assess various factors. Below is the detailed list of these considerations.

Migration Downtime

Regardless of the migration approach employed for workloads, there exists a potential factor of downtime. Downtime is often a result of the necessity to quiesce or temporarily pause an application or dataset to guarantee the continuity of its copy, validation, resetting the server parameters and other critical processes.
Best Practice - It is important to connect with business and application teams to inform, plan, and analyze the impact of downtime.

Version compatibility

There are differences in the major versions of PostgreSQL supported by Azure Database for PostgreSQL – Single Server and Flexible Server. Depending on the major version you are using with Azure Database for PostgreSQL – Single Server, you may need to migrate across versions.
Application compatibility issues can arise when migrating to a different version of PostgreSQL. These issues are primarily due to changes in the database system's behavior, features, or syntax between versions, Deprecated Features, Changes in Default Setting, Extension Compatibility etc.

Best Practice - Once you have decided which version to migrate to, review the changes between the pre-migration and post-migration versions. For more details refer to Supported versions - Azure Database for PostgreSQL. Comprehensive testing is crucial to identify and address database and application compatibility issues before migrating to a new PostgreSQL version.

Cost & Sizing

• Cost
  With Flexible Server, you can take advantage of stop/start features, a burstable service tier, and reserved instances for savings, and pay for storage only when your database has stopped running. For more details refer to Pricing.
  Best Practice – Estimate the flexible server costing with the help of pricing calculator and share it with the team.
• Sizing
  

  Consider the following options while choosing an Azure Database for PostgreSQL – Flexible Server tier: Instance Type, vCores, Memory, Storage, Backup Storage. Read more about various tier and offerings here: Compute and Storage options in Azure Database for PostgreSQL – Flexible Server.
  Commence by aligning your sizing with the apple-apple comparison. Our observations indicate improved performance in the flexible server with an equivalent single server configuration. The SKU can be changed to match the workload needs post migration but please beware that changing SKU may necessitate downtime as server needs to be restarted.

  Best Practice - Regardless of the SKU of the Azure Database for PostgreSQL – Single Server you are migrating from, choose a SKU with at least 4 cores to complete the migration quickly while using single to flexible migration tool.
  Single to Flexible Server Migration Tool runs in a container on Azure Database for PostgreSQL - Flexible Server. The larger the Azure Database for PostgreSQL – Flexible Server SKU, the more resources available to containers, which can speed up migrations.

Resilience
Azure Database for PostgreSQL – Single Server comes with built-in high availability, redundancy, and resiliency features without the need to configure any additional components. Azure Database for PostgreSQL – Flexible Server supports two high availability deployment models: zone-redundant HA and same-zone HA. Because the high availability configuration deploys identical compute and storage to the primary, its costs must also be estimated.
Best Practice - Please note that when migrating with the Azure Database for PostgreSQL – Single to Flexible server migration tool, the Azure Database for PostgreSQL – Flexible Server must not have HA options or read-only replicas enabled. You can enable them after the migration is complete. HA/Read replicas can be enabled to your primary Flexible server without any downtime (no restart required).

Networking & Security
Azure Database for PostgreSQL – Flexible Server instance support choosing one of the following networking options: Private access (VNet integration),⁠ private link (in public preview) or public access (allowed IP addresses). For private and secure network communication, refer networking overview.

When using the Azure Database for PostgreSQL – Single server to Flexible server migration tool, the Azure Database for PostgreSQL – Single Server and Flexible Server must be able to connect via network. If the Azure Database for PostgreSQL – Single Server has public access, you can use it as is, but if the Azure Database for PostgreSQL – Single Server has private access, please refer to the network configuration.

• Deploy Azure Database for PostgreSQL – Flexible Server in the same VNET as Azure Database for PostgreSQL – Single Server's Private Endpoint and allow connections with NSG.
  

  

• Azure Database for PostgreSQL – Flexible Server is deployed in a VNET different from the Private Endpoint of Azure Database for PostgreSQL – Single Server, and the VNET in which the Private Endpoint is created and the VNET in which Azure Database for PostgreSQL – Flexible Server is deployed are connected using VNET peering.
  

Security: User Identity and Access Management

Azure Database for PostgreSQL offers two methods to authenticate to your Database: PostgreSQL authentication and Microsoft Entra authentication. Read more here: Microsoft Entra authentication with PostgreSQL Flexible Server. Also read about: Security in Azure Database for PostgreSQL - Flexible Server.
Best Practice - Azure Database for PostgreSQL – Single server to Flexible server migration tool does not migrate Entra users to the target server, so create all Entra users manually in advance.

Performance

• Performance factors for the migration activity
  Below are some of the factors that can be considered for improving migration performance. Refer to Improve migration speed.
  
  • Increasing Source & Destination compute and IO by scaling up SKU.
  • Parallel migration of tables with Single to Flexible migration tool by satisfying conditions.
• Performance optimization post migration activity
  Below are some of the factors that can be considered for improving the performance after migration for the flexible.
  
  • Connection Pooling
    • Azure Database for PostgreSQL – Flexible Server includes a built–in PgBouncer for connection pooling. If you have configured PgBouncer for connection pooling in Azure Database for PostgreSQL – Single Server, consider utilizing the built-in solution in Azure Database for PostgreSQL – Flexible Server during migration. See this documentation for Flexible Server's built-in PgBouncer - PgBouncer - Azure Database for PostgreSQL - Flexible Server.
    • Also, learn more about PostgreSQL connection pooling design patterns using PgBouncer - Connection pooling best practices - Azure Database for PostgreSQL - Flexible Server.

Other Key Considerations

• Support: Consider the support you need for your data and applications. Make sure you have a plan in place to ensure that you receive the necessary support and guidance as you migrate. Contact Microsoft support team.
• Zone Awareness & Availability by region: Azure Database for PostgreSQL – Flexible Server can be co-located in the same availability zone as application servers, minimizing latency. 

Please refer to Availability zone deployment for more details.

For best performance and lowest latency, locate your Azure Database for PostgreSQL in the same region as your client application. Azure Database for PostgreSQL is continually expanding into new regions. To check the latest availability by region, see Products available by region. In case the flexible server is not available in the region, it is recommended to move both the application and database to another region nearby.

Migration Options & Approaches

There are different methods for migrating from Azure Database for PostgreSQL – Single Server to Flexible Server. The following diagram shows different methods:

The table below shows the differences between each migration approach.

For successful data migration, it is important to understand the characteristics of the business that uses the database and decide how to do it. Select offline migration if you can completely shut down the applications connecting to the source databases, perform migration, and restart the system at the destination. Offline migration is the recommended option to perform Azure Database for PostgreSQL – Single Server to Flexible Server migrations because there are no restrictions on the database objects that can be processed, and it is simple and uncomplicated to perform. If your database is always busy and you cannot afford a long outage, then consider migrating online.

Please note that below Items need to be manually migrated as these cannot be migrated using the migration tools. Please consider manual migration of the following items:

• Firewall Rules
• Server Parameters
• Tags
• Alerts
• AAD Users

Migration Phases

Below are the different phases of migration:

Discovery & Assessment

In this phase, identify the source Azure Database for PostgreSQL – Single Server, define the scope, identify the applications, and evaluate the impact of migration.
Perform a discovery of Azure Database for PostgreSQL – Single Server. The following Kusto query will help you find an existing Single Server in Azure Resource Graph. Please note that you need read access to the resources you are querying to obtain the results.

• List of Azure Database for PostgreSQL – Single Server
• SKU
• Location
• Version
• Network configurations
• Storage
• Backup
• Replication
• Read Replicas

Best Practices - One of the examples is to create a list Excel capturing above details.

Regarding the assessment, Pre-migration validation tool assesses the database level of source single servers and shows potential problems along with remedial actions that should be taken to fix them. By running this validation beforehand, you can identify what needs to be prepared/fixed.

Plan & design

• Ensure to evaluate the key considerations impacting the migration plan.
• Define and establish target state architecture.
• Finalize the migration method/approach.
• Validate & finalize the Network connectivity strategy.
• Review migration readiness.
• Pre-migration validations:
  • Pre-migration validation helps you verify if the migration setup is intact to perform a successful migration. Checks are done against a rule set and any potential problems along with the remedial actions are shown to take corrective measures. Please see – Pre-migration validations.
  • Data Validation
    Typically, all migration tools show the number of tables copied from source to target server. You need to manually validate the data in target server post migration.
• Dry Run in Lower environments:
  Conduct a small POC/Pilot before actual migration to assess complexities, feasibility, and fine tune the migration plan accordingly.

Best Practices - Use the same configuration, migration approach & same volume of data (if possible) in lower environments.

Migrate

• Migrate your services as per the approved plan.
• Run smoke test in Production environment to identify any teething issues. Refer to troubleshooting guides if you encounter any issues:
  
  • Common errors and special scenarios for PostgreSQL Migration
  • Troubleshooting networking and connectivity errors in Single to Flex Migration tool
  • Common issues - Azure Database Migration Service | Microsoft Learn
• Plan for Read replicas & HA:
  • Enabling read replicas and HA (Zone redundancy) need to be done manually post migration.

Best Practice - Do not to leave the migration for a long time & do cutover as soon as possible e.g. 1 day. Sooner the cutover the       chances of migration failure is minimal.

Monitor and Govern

• Azure Database for PostgreSQL uses Azure Monitor to provide several options for monitoring your cache instances. Use these tools to monitor the health of your Azure Database for PostgreSQL instances and to help you manage your caching applications.
• Use insights to understand performance and utilization. For all your Azure Database for PostgreSQL resources, Azure Monitor for Azure Database for PostgreSQL provides a unified, interactive view of overall performance, failures, capacity and operational health. For more details refer to: Monitoring and metrics - Azure Database for PostgreSQL - Flexible Server.
• Identify gaps in your organization's current state of governance. Assess your current state and future state to establish a vision for applying the Cloud Adoption Framework.

Optimize and Modernize

Conduct Well-Architected (WAF) Review to ensure that the workloads are optimized as per the best practices and standards.

Conclusion

After reading this article, you should have a better understanding of the various considerations and approaches for migrating from Azure Database for PostgreSQL – Single Server to Flexible Server and be able to make a more knowledgeable decision about the best tool and steps to use to complete the process.

If you have any feedback or questions about the information provided above, please leave a comment below or email us at AskAzureDBforPostgreSQL@service.microsoft.com. Thank you!