A Step-by-Step Guide to Migrate AWS RDS PostgreSQL to Azure Database for PostgreSQL

Quick Summary

Table of Contents

Introduction

Many organizations have moved their applications to Microsoft Azure to take advantage of its scalability, security, and seamless integration with the Azure ecosystem. However, in most cases, the PostgreSQL database remains on AWS RDS, often due to legacy infrastructure or decisions made before cloud consolidation became a priority.

Running applications on Azure while keeping the database on AWS isn’t ideal. It can slow things down, increase data transfer costs, and make it harder to manage identity, networking, and monitoring across two different cloud platforms.

It’s a smart move to bring your PostgreSQL database into Azure as well to simplify your architecture and avoid these issues.

Azure’s Flexible Server for PostgreSQL is a modern, fully managed solution built for today’s workloads. It offers high availability, built-in connection pooling, private networking, stop/start capabilities to save costs, and smooth integration with other Azure services.

With Azure’s older Single Server option being retired in March 2025, Flexible Server isn’t just a better choice. It’s the future. (Source)

In this tutorial, our Microsoft Azure developers have crafted this step-by-step tutorial to provide you with clear instructions and ensure minimal downtime while migrating your PostgreSQL database from AWS RDS to Azure.

Let’s get started.

Key Reasons to Migrate AWS RDS PostgreSQL to Azure Database for PostgreSQL

Here are the top reasons to migrate your PostgreSQL database from AWS RDS to Azure Database for PostgreSQL.
1. Single Server Is Being Retired: In March 2025, Azure retired PostgreSQL Single Server SKU, making Flexible Server the default and future-proof choice.
2. Reduced Latency for Azure Workloads: Keeping your database close to Azure-based applications improves response times and eliminates cross-cloud data transfer overhead.
3. Built-In High Availability and Security: Flexible Server includes zone-redundant HA, private networking, and native pgBouncer support for secure, reliable performance.
4. Cost Optimization Options: Optimize spend using burstable compute, stop/start capabilities for non-production workloads, and discounts via reserved instances.
5. Access to Advanced Features: You also gain access to emerging features like vector search, available through Azure Cosmos DB for PostgreSQL, something AWS RDS doesn’t support.
6. Unified Identity and Monitoring: You can manage authentication and observability using Azure-native tools like Microsoft Entra ID, Monitor, and Log Analytics.
7. Seamless Azure Ecosystem Integration: Native integration with services like AKS, App Services, and Functions reduces integration effort and speeds up time to production.

Step-by-Step Migration from AWS RDS to Azure PostgreSQL

We’ll break the migration into 8 clear stages, each with technical details, tools, and best practices.

Step 1: Know Your Source And Target Platforms

Before you start, compare your current AWS RDS setup with what Azure Flexible Server offers. Understanding the differences helps prevent migration issues and plan better.

Step 2: Choose the Right Migration Strategy

Pick the right migration method based on how much downtime you can allow and the size of your database.

Step 3: Prepare For Migration Checklist

Before starting the migration, make sure both your AWS RDS and Azure PostgreSQL environments are properly configured and compatible.

These pre-checks are essential, especially if you’re using logical replication or Azure Database Migration Service. They help reduce downtime and avoid common errors.

1. Version Compatibility

• Source: AWS RDS PostgreSQL must be version 11 or higher
• Target: Azure PostgreSQL Flexible Server supports versions 11 to 16

2. List Extensions on RDS

Check which extensions are installed on your RDS instance:

3. Enable Logical Decoding on RDS

Enable logical replication by modifying the RDS parameter group (requires a reboot):

Note: Apply these settings via a custom DB parameter group. A reboot is required for the changes to take effect.

4.Grant Replication Access

Allow your migration user to use replication features:

5.Network Access

Control how your database is accessed, either securely within a private network or through limited public exposure.

• Private Access (Recommended): Connect your server privately via Azure VNet to keep traffic internal and secure.
• Note: This requires a delegated subnet in your VNet during setup.
• Public Access: Enable only when required, and set strict firewall rules to restrict IP access.
• Site-to-Site VPN for Azure DMS: If you prefer a secure connection during migration, consider deploying Azure Database Migration Service inside an Azure VNet with a site-to-site VPN connection to your AWS VPC.

This approach avoids exposing your source RDS instance over the public internet and ensures end-to-end encrypted traffic between source and target.

6.Dump and Recreate Users

Dump global roles from AWS RDS:

Due to platform-level restrictions, Azure Flexible Server does not allow restoring roles with full superuser privileges. Instead, manually recreate users with necessary roles like CREATEDB or LOGIN.

7. Provision Extra Storage on Azure

• During replication or WAL replay, storage usage spikes. To avoid issues:
• Allocate 20–30% more storage on your Azure Flexible Server than your current RDS usage.
• This ensures there’s enough room for migration logs, temporary files, and write-ahead logs.

Step 4: Provision Azure PostgreSQL Flexible Server

Set up your target database in Azure by provisioning a PostgreSQL Flexible Server. This will be the destination for your migrated data, so it’s important to configure it correctly based on your workload, security, and availability needs.

How to Create the Server (Using Azure Portal)

1. Navigate to:

Azure Portal → Create a Resource → Databases → Azure Database for PostgreSQL (Flexible Server)

2. Fill in the following sections during setup:

➧ Basics: Start by defining where your server lives and how it will be identified within your Azure environment.

• Subscription: Choose the Azure subscription that will host and bill for this server.
• Resource Group: Choose an existing one or create a new resource group.
• Server Name: Enter a globally unique name for your server.

➧ Compute + Storage: Choose performance and storage options that align with your current workload and leave room for future scale.
● Tier Options:

• Burstable: Good for development or testing environments with light, infrequent usage.
• General Purpose: A solid choice for most production workloads with standard performance needs.
• Memory Optimized: Best for high-throughput or memory-intensive applications.

● Storage: Select based on current DB size plus 20–30% extra for migration overhead (WAL, temp files, etc.).

3. High Availability:

Decide how resilient your server needs to be in the event of regional or zone-level failures.

• Zone-redundant (Recommended): Offers higher fault tolerance and a 99.95% SLA by replicating across multiple zones.
• Single-AZ: Lower-cost option suitable for development or non-critical systems.

4. Networking:

Control how your database is accessed, either securely within a private network or through limited public exposure.

• Private Access (Recommended): Connect your server privately via Azure VNet to keep traffic internal and secure.
• Public Access: Enable only when required, and set strict firewall rules to restrict IP access.

5. Authentication:

Choose how users will log in and manage access to your PostgreSQL server.

• PostgreSQL Password Authentication: Use this as the default during initial setup.
• Azure Active Directory (Optional): Can be enabled post-deployment for centralized identity and access management.

6. Post-Creation Configuration:

Fine-tune database parameters to align performance with your specific workload needs.

• work_mem: Controls memory per operation. Increase for complex queries.
• shared_buffers: Recommended to set at 25–40% of available memory.
• You can configure these settings through:

• ● Azure Portal → Flexible Server → Server Parameters
• ● Or use Azure CLI for scripted deployments.

Step 5A: Option A: Offline Migration (pg_dump / pg_restore)

This method is ideal for small to mid-sized databases (typically under 200 GB) and applications where a full downtime window is acceptable. You’ll export the database from AWS RDS and import it into Azure using standard PostgreSQL tools.

Steps to Perform Offline Migration

Run these commands from a jump host or VM with network access to RDS and Azure Flexible Server.

Tips for Better Performance

• Use with to enable parallel restore, e.g., --jobs=N

pg_restore
--jobs=4

• After restoring, run:

• This updates query planner statistics and improves performance.

Step 5B: Option B: Online Migration (Azure DMS)

This method is best for large databases or mission-critical apps that cannot afford extended downtime. Azure Database Migration Service (DMS) enables continuous replication with minimal disruption during cutover. Follow the given steps:

1. Create Azure Migration Service

• In the Azure Portal, go to:

Azure Portal → Create → Migration Services → Azure Database for PostgreSQL.

• Choose the Premium SKU – this is required to support logical replication.

2. Set Up Migration Project

• Source: PostgreSQL (AWS RDS)
• Target: Azure Database for PostgreSQL – Flexible Server

3. Connect & Validate

• Enter connection details for both source and target:

▸ Hostname
▸ Port
▸ Database name
▸ Username/password

• Azure DMS will validate the connections and check for replication compatibility.

4. Start Continuous Replication

Azure DMS begins real-time data replication from AWS RDS to Azure Flexible Server.

• It tracks LSN (Log Sequence Number) to monitor data changes.
• You can monitor replication lag metrics directly in the Azure Portal.

Azure DMS also provides a monitoring dashboard that shows replication metrics, including total bytes copied, LSN (Log Sequence Number) progress, and current latency. Use these metrics to ensure replication health before cutover.

5. Cutover Process

When you’re ready to complete the migration:

1. Pause all application writes to the AWS RDS database.
2. Wait until replication lag = 0 (i.e., target is fully caught up).
3. Complete the migration in the Azure DMS portal.

6. Final Step

• Update your application’s connection string to point to the new Azure PostgreSQL Flexible Server.
• Resume normal operations.

For a smooth and flawless migration from AWS RDS PostgreSQL to Azure PostgreSQL, hire a PostgreSQL developer with expertise in both AWS and Azure. Their specialized knowledge ensures minimal downtime, accurate data transfer, and seamless database integration.

Step 6: Validate Migration

Once the migration is complete, it’s essential to verify that everything has been transferred correctly and that your new Azure PostgreSQL environment is production-ready. Use the checklist below to validate data, structure, performance, backups, and high availability.

Step 7: Cost Optimization Tips

Here are a few effective ways to reduce your Azure PostgreSQL costs:

• Use the Burstable tier for development and testing environments. This option can lower costs by up to 70% compared to higher-performance tiers.
• Set up alerts to monitor when storage auto-growth is triggered. This helps you stay ahead of unexpected cost spikes.
• Consider Reserved Instances with 1-year or 3-year commitments. These can save you up to 52% on compute costs.
• Be aware of AWS data transfer charges during migration. Outbound data from AWS typically costs around $0.02 per GB.

Step 8: Troubleshooting Cheat Sheet

If you run into issues during or after migration, this quick fix given below can help you identify and resolve common problems.

Conclusion

Frequently Asked Questions (FAQs)

How do I migrate AWS RDS PostgreSQL to Azure Database for PostgreSQL with minimal downtime?

Use Azure Database Migration Service (DMS) or logical replication. Both options support near-zero downtime by continuously syncing changes from AWS to Azure until cutover.

Can I use pg_dump and pg_restore to migrate from AWS RDS to Azure PostgreSQL?

Yes, pg_dump and pg_restore are ideal for offline migrations where downtime is acceptable. This method is best for databases under 200 GB.

What’s the difference between Azure PostgreSQL Single Server and Flexible Server?

Flexible Server provides key advantages like zone-redundant high availability, private networking, and the ability to stop/start instances to save costs. It’s also the default choice moving forward, as Single Server is retired in March 2025.

Do I need to enable logical replication on AWS RDS before using Azure DMS?

Yes, enable logical replication in your RDS parameter group by setting rds.logical_replication = 1, then reboot the instance to apply the change.

Are there any limitations when migrating PostgreSQL roles from AWS to Azure?

Yes. Azure doesn’t support full superuser privileges. You must manually recreate roles with needed privileges like CREATEDB and LOGIN after dumping them using pg_dumpall --globals-only.