Skip to main content
This page describes how PostgreSQL Flexible Server maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

How the targets compare

Each row compares a capability of PostgreSQL Flexible Server with its adaptation on each target. A dash means this profile does not state the capability for that target.

Cloud Adapter

On AWS

RDS PostgreSQL

An Azure flexible server becomes an RDS PostgreSQL instance. Your application keeps using the PostgreSQL protocol. Zone-redundant high availability maps to Multi-AZ, and server settings become an RDS parameter group.

Management and database connections

The adapter handles the Azure server-management calls and applies the requested target database configuration. SQL connections use the target database engine. Review both paths: accepting a server update does not make a setting active, and a running server does not establish that the application can authenticate or load its extensions.

Data and failover

Transfer the database contents separately, using compatible engine versions. Include users, grants, extensions, and scheduled jobs in the cutover. Update connection configuration and test reconnection after failover. The source backup history does not become a set of target restore points.

Compatibility differences

The build rejects Microsoft Entra authentication because RDS does not accept those tokens; it does not substitute a password. It also rejects extensions outside RDS’s supported set, including TimescaleDB, before they can fail on CREATE EXTENSION.

On Google Cloud

Cloud SQL for PostgreSQL

A flexible server becomes a Cloud SQL for PostgreSQL instance, with zone-redundant high availability mapped to a regional instance and server settings to database flags. Your application continues to use the PostgreSQL protocol.

Management and database connections

The adapter handles the Azure server-management calls and applies the requested target database configuration. SQL connections use the target database engine. Review both paths: accepting a server update does not make a setting active, and a running server does not establish that the application can authenticate or load its extensions.

Data and failover

Transfer the database contents separately, using compatible engine versions. Include users, grants, extensions, and scheduled jobs in the cutover. Update connection configuration and test reconnection after failover. The source backup history does not become a set of target restore points.

Compatibility differences

Microsoft Entra tokens are not accepted by the target. The build rejects this authentication method and any extension outside the target’s allowed list.

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.