What happens to Azure Database for PostgreSQL - Single Server after the retirement announcement?
APPLIES TO: Azure Database for PostgreSQL - Single Server
Azure Database for PostgreSQL - Single Server is on the retirement path and is scheduled for retirement by March 28, 2025.
Azure Database for PostgreSQL – Single Server generally became available in 2018. Given customer feedback and new advancements in the computation, availability, scalability, and performance capabilities in the Azure database landscape, the Single Server offering needs to be retired and upgraded with a new architecture. Azure Database for PostgreSQL - Flexible Server is the next generation of the service and brings you the best of Azure open-source database platform.
As part of this retirement, we no longer support creating new single server instances from the Azure portal beginning November 30, 2023. If you need to create single server instances to meet business continuity needs, you can continue to use Azure CLI and the ARM template. However, as of March 2025, these methods will no longer be used.
If you currently have an Azure Database for PostgreSQL - Single Server service hosting production servers, we're glad to inform you that you can migrate your Azure Database for PostgreSQL - Single Server to the Azure Database for PostgreSQL - Flexible Server.
Azure Database for PostgreSQL - Flexible Server is a fully managed production-ready database service designed for more granular control and flexibility over database management functions and configuration settings. For more information about Azure Database for PostgreSQL - Flexible Server, visit Azure Database for PostgreSQL - Flexible Server.
Migrate from Azure Database for PostgreSQL - Single Server to Azure Database for PostgreSQL - Flexible Server
Learn how to migrate from Azure Database for PostgreSQL - Single Server to Azure Database for PostgreSQL - Flexible Server using the Single Server to Flexible Server migration tool.
Frequently Asked Questions (FAQs)
Q. Why is Azure Database for PostgreSQL- Single Server being retired?
A. Azure Database for PostgreSQL – Single Server generally became available in 2018. Given customer feedback and new advancements in the computation, availability, scalability, and performance capabilities in the Azure database landscape, the Single Server offering needs to be retired and upgraded with a new architecture. Azure Database for PostgreSQL - Flexible Server is the next generation of the service and brings you the best of Azure open-source database platform.
Q. Why am I being asked to migrate to Azure Database for PostgreSQL - Flexible Server?
A. Azure Database for PostgreSQL - Flexible Server is the best platform for running all your open-source PostgreSQL workloads on Azure. Azure Database for PostgreSQL - Flexible Server is economical, provides better performance across all service tiers, and more ways to control your costs for cheaper and faster disaster recovery. Other improvements to the flexible server include:
- Support for Postgres version 11 and newer, plus built-in security enhancements
- Better price performance with support for burstable tier compute options.
- Improved uptime by configuring hot standby on the same or a different availability zone and user-controlled maintenance windows.
- A simplified developer experience for high-performance data workloads.
Q. How soon must I migrate my Single Server to a Flexible Server?
A. Azure Database for PostgreSQL - Single Server is scheduled for retirement by March 28, 2025, so we strongly recommend migrating your Single Server to a Flexible Server at the earliest opportunity to ensure ample time to run through the migration lifecycle and use the benefits offered by the Flexible Server.
Q. What happens to my existing Azure Database for PostgreSQL - Single Server instances?
A. Your existing Azure Database for PostgreSQL - Single Server workloads will continue to be supported until March 2025.
Q. Can I still create a new version 11 Azure Database for PostgreSQL - Single Server after the community EOL date in November 2023?
A. Beginning November 9 2023, you'll no longer be able to create new single server instances for PostgreSQL version 11 through the Azure portal. However, you can still make them via CLI until November 2024. We will continue to support single servers through our versioning support policy. It would be best to start migrating to Azure Database for PostgreSQL - Flexible Server immediately.
Q. Can I continue running my Azure Database for PostgreSQL - Single Server beyond the sunset date of March 28, 2025?
A. We plan to support Single Server until the sunset date of March 28, 2025, and we strongly advise that you start planning your migration as soon as possible. We plan to end support for single server deployments at the sunset data of March 28, 2025.
Q. After the Single Server retirement announcement, what if I still need to create a new single server to meet my business needs?
A. We aren't stopping the ability to create new single servers immediately, so you can continue to create new single servers through CLI to meet your business needs for all PostgreSQL versions supported on Azure Database for PostgreSQL – Single Server. We strongly encourage you to explore Flexible Server and see if that will meet your needs. Don't hesitate to contact us if necessary so we can guide you and suggest the best path forward for you.
Q. Are there any additional costs associated with performing the migration?
A. You pay for the target flexible server and the source single server during the migration. The configuration and computing of the target flexible server will determine the extra costs incurred (see Pricing for more details). Once you've decommissioned the source single server after a successful migration, you only pay for your flexible server. Using the Single Server to Flexible Server migration tool doesn't cost extra. If you have questions or concerns about the cost of migrating your single server to a flexible server, contact your Microsoft account representative.
Q. Will my billing be affected by running Azure Database for PostgreSQL - Flexible Server instead of Azure Database for PostgreSQL - Single Server?
A. The billing should be comparable if you choose a similar configuration to your Azure Database for PostgreSQL - Single Server. However, if you select the same zone or zone redundant with high availability for the target flexible server, your bill will be higher than it was on your single server. Same zone or zone redundant high availability requires an additional hot standby server to be spun up and store redundant backup data, hence the added cost for the second server. This architecture enables reduced downtime during unplanned outages and planned maintenance. Generally speaking, Flexible Server provides better price performance, however, this is dependent on your workload.
Q. Will I incur downtime when I migrate my Azure Database from PostgreSQL - Single Server to a Flexible Server?
A. Currently, the Single Server to Flexible Server migration tool only supports offline migrations. Offline migration requires downtime to your applications during the migration process. For more information, see Migration tool - Azure Database for PostgreSQL Single Server to Flexible Server.
Downtime depends on several factors, including the number of databases, size of your databases, number of tables inside each database, number of indexes, and the distribution of data across tables. It also depends on the SKU of the source and target server and the IOPS available on the source and target server.
Given the many factors involved in a migration, the best approach to estimate downtime to your application is to try the migration on a PITR server restored from the primary server to plan for your production migration.
Offline migrations are less complex, with few chances of failure, and are the recommended way to perform migrations from a single server to a flexible server for workloads with service windows.
You can contact your account teams if downtime requirements aren't met by the Offline migrations provided by a single server to a Flexible migration tool.
Support for online migration is coming soon.
Q. Will there be future updates to Single Server to support the latest PostgreSQL versions?
A. We recommend you migrate to Flexible Server if you must run on the latest PostgreSQL engine versions. We continue to deploy minor versions released by the community for Postgres version 11 until it's retired by the community in Nov'2023.
We're extending support for Postgres version 11 past the community retirement date and will support PostgreSQL version 11 on both Single Server and Flexible Server to ease this transition. Consider migrating to Flexible Server to use the benefits of the latest Postgres engine versions.
Q. How does the Flexible Server 99.99% availability SLA differ from Single Server?
A. Flexible Server zone-redundant deployment provides 99.99% availability with zonal-level resiliency, and Single Server delivers 99.99% availability but without zonal resiliency. Flexible Server High Availability (HA) architecture deploys a hot standby server with redundant compute and storage (with each site's data stored in 3x copies). A Single Server HA architecture doesn't have a passive hot standby to help recover from zonal failures. Flexible Server HA architecture reduces downtime during unplanned outages and planned maintenance.
Q. My Single Server is deployed in a region that doesn't support Flexible Server. How should I proceed with migration?
A. We're close to regional parity with a Single Server. These are the regions with no Flexible Server presence.
- China East (CE and CE2),
- China North (CN and CN2)
- West India
- Sweden North
We recommend migrating to CN3/CE3, Central India, Sweden Central and Sweden South regions. Q. I have a private link configured for my single server, and this feature is not currently supported in Flexible Server. How do I migrate?
A. Flexible Server support for private-link is our highest priority and on the roadmap. This feature is planned to launch in Q4 2023. Another option is to consider migrating to VNET injected flexible server.
Q. Is there an option to roll back Single Server to a Flexible Server migration?
A. You can perform any number of test migrations, test the success of your migration, and perform the final migration once you're ready. Test migrations don't affect the single server source, which remains operational until you perform the migration. If there are any errors during the test migration, you can postpone the final migration and keep your source server running. You can then reattempt the final migration after you resolve the errors. After you've performed a final migration to a flexible server and opened it up for the production workload, you'll lose the ability to go back to single server without incurring a data loss.
Q. How should I migrate my DB (> 1TB)
A. The Single Server to Flexible Server migration tool can migrate databases of all sizes from a Single Server to a Flexible Server. The new version of the tool has no restrictions regarding the size of the databases.
Q. Is cross-region migration supported?
A. Currently, the Single Server to Flexible Server migration tool doesn't support cross-region migrations. It is supported at a later point in time. You can use the pg_dump/pg_restore to perform migrations across regions.
Cross-region data migrations should be avoided because the migration takes a long time to complete. A simpler way to do this will be to start a read-replica in the target GeoRegion, failover your application, and follow the steps outlined earlier.
Q. Is cross-subscription migration supported?
A. The Single Server to Flexible Server migration tool supports cross-subscription migrations.
Q. Is cross-resource group subscription-supported?
A. the Single Server to Flexible Server migration tool supports cross-resource group migrations.
Q. Is there cross-version support?
A. The Single Server to Flexible Server migration service supports migrating from a lower PostgreSQL version (PG 9.5 and above) to any higher version. As always, application compatibility with higher PostgreSQL versions should be checked beforehand.
Single Server to Flexible Server migration tool
The Single Server to Flexible Server migration tool is a powerful tool that allows you to migrate your SQL Server database from a single server to a flexible server with ease. With this tool, you can easily move your database from an on-premises server or a virtual machine to a flexible server in the cloud, allowing you to take advantage of the scalability and flexibility of cloud computing.
Q. Which data, schema, and metadata components are migrated as part of the migration?
A. the Single Server to Flexible Server migration tool migrates schema, data, and metadata from the source to the destination. All the following data, schema, and metadata components are migrated as part of the database migration:
- All tables from all databases/schemas.
- Primary key
- Data type
- Ordinal position
- Default value
- Autoincrement attributes
- Secondary indexes
- Stored Procedures
- Foreign key constraints
Q. What's the difference between offline and online migration?
A. the Single Server to Flexible Server migration tool supports offline migration now, with online migrations coming soon. With an offline migration, application downtime starts when the migration begins. With an online migration, downtime is limited to the time required to cut over at the end of migration but uses a logical replication mechanism. Your Data/Schema must pass these open-source PG engine restrictions for online migration. We suggest you test offline migration to determine whether the downtime is acceptable.
Online and Offline migrations are compared in the following table:
|Area||Online migration||Offline migration|
|Database availability for reads during migration||Available||Available|
|Database availability for writing during migration||Available||Generally, not recommended. Any 'writes' initiated after the migration isn't captured or migrated|
|Application Suitability||Applications that need maximum uptime||Applications that can afford a planned downtime window or have schema/workload restrictions that prohibit online migration|
|Suitability for Write-heavy workloads||Suitable but expected to reduce the workload during migration||This is only a recommended solution if you can disable writes during the migration. Any writes at the source aren't migrated to the target server after the migration begins|
|Manual Cutover||Required||Not required|
|Downtime required||Small and fixed irrespective of the data size||Proportional to the data size and other factors. It could be as small as a few mins for smaller databases to a few hours for larger databases|
|Migration time||Depends on the Database size and the write activity until cutover||Depends on the Database size|
Q. Are there any recommendations for optimizing the performance of the Single Server to Flexible Server migration tool?
A. Yes. To perform faster migrations, pick a higher SKU for your flexible server. Pick a minimum 4VCore or higher to complete the migration quickly. You can always change the SKU to match the application needs post-migration.
Q. How long does performing an offline migration with the Single Server to Flexible Server migration tool take?
A. The following table shows the time for performing offline migrations for databases of various sizes using the Single Server to Flexible Server migration tool. The migration was performed using a flexible server with the SKU:
Standard_D4ds_v4(4 cores, 16GB Memory, 128GB disk and 500 IOPS)
|Database Size||Time (HH:MM)|
The numbers above approximate the time taken to complete the migration. To get the precise time required for migrating to your Server, we strongly recommend taking a PITR (point in time restore) of your single server and running it against the Single Server to Flexible Server migration tool.
Q. How long does performing an online migration with the Single Server to Flexible Server migration tool take?
A. Online migration involves the following steps:
- Initial copy of databases
- Change data capture - Replaying all the transactions on the source during step #1 to the target.
The time taken in step #1 is the same as for offline migrations (refer to the previous question).
The time taken for step #2 depends on the transactions that occur on the source. If it's a write-intensive workload, the time taken for step #2 will be longer.
Q. I have further questions about retirement.
A. You can get further information in a few different ways.
Gett answers from community experts in Microsoft Q&A.
You can contact the Azure Database for PostgreSQL product team.
If you have a support plan and you need technical help, create a support request:
- For Summary, type a description of your issue.
- For Issue type, select Technical.
- For Subscription, select your subscription.
- For Service, select My services.
- For Service type, select Azure Database for PostgreSQL single server.
- For Resource, select your resource.
- For Problem type, select Migrating to Azure DB for PostgreSQL.
- For Problem subtype, select migrating from single to flexible server.
This article is not for Azure Database for PostgreSQL - Flexible Server users. It is for Azure Database for PostgreSQL - Single Server customers who need to upgrade to Azure Database for PostgreSQL - Flexible Server.
We know migrating services can be a frustrating experience, and we apologize in advance for any inconvenience this might cause you. You can choose what scenario best works for you and your environment.