We encountered a support case involving Azure Database for PostgreSQL Flexible Server where a customer attempted to scale up their server from non-Confidential compute SKU to Confidential compute SKU but was unable to complete the operation. This blog explains the root cause, resolution steps, and best practices to prevent similar issues when working with Confidential and non-Confidential Compute SKUs.
Co-authored with HaiderZ-MSFT
Issue Summary
The customer attempted to change the server configuration from Standard_D4ds_v5 (non-Confidential Compute) to Standard_DC4ads_v5 (Confidential Compute) in the West Europe region.
The goal was to enhance the performance and security profile of the server. However, the SKU change could not be completed due to a mismatch in security profiles between the current and target SKUs.
Root Cause
The issue occurred because SKU changes from non-Confidential to Confidential Compute types are not supported in Azure Database for PostgreSQL Flexible Server.
- Each compute type uses different underlying hardware and isolation technologies.
- As documented in Azure Confidential Computing for PostgreSQL Flexible Server, operations such as Point-in-Time Restore (PITR) from non-Confidential Compute SKUs to Confidential ones aren’t allowed.
- Similarly, direct SKU transitions between these compute types are not supported due to this security model difference.
Mitigation
To resolve the issue, the customer was advised to migrate the data to a new server created with the desired compute SKU (Standard_DC4ads_v5).
This ensures compatibility while achieving the intended performance and security goals.
Steps:
- Create a new PostgreSQL Flexible Server with the desired SKU (Confidential Compute).
- Use native PostgreSQL tools to migrate data:
pg_dump -h <source_server> -U <user> -Fc -f backup.dump
pg_restore -h <target_server> -U <user> -d <database> -c backup.dump
3. Validate connectivity and performance on the new server.
4. Decommission the old server once migration is confirmed successful.
Prevention & Best Practices
To avoid similar issues in the future:
- Review documentation before performing SKU changes or scaling operations: Azure Confidential Computing for PostgreSQL Flexible Server
- Confirm compute type compatibility when planning scale or migration operations.
- Plan migrations proactively if you anticipate needing a different compute security profile.
- Use tools such as pg_dump / pg_restore or Azure Database Migration Service.
- Check regional availability for Confidential Compute SKUs before deployment.
Why these matters
Understanding the distinction between Confidential and non-Confidential Compute is essential to maintain healthy business progress.
By reviewing compute compatibility and following the documented best practices, customers can ensure smooth scaling, enhanced security, and predictable database performance.