Cloud SQL for PostgreSQL

This page describes how Cloud SQL for PostgreSQL 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 Cloud SQL for PostgreSQL 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

Cloud SQL for PostgreSQL becomes an RDS PostgreSQL instance, and the application keeps the PostgreSQL protocol.

​

Connection setup and instance changes

The source management API and the database protocol serve different purposes. The adapter creates and configures the target instance and handles the connector certificate exchange; SQL then uses the target engine. Verify the complete connection sequence with the actual client library, including token acquisition and certificate renewal.

​

Moving the database

Provisioning a target instance does not copy data, users, or backup history. Transfer the required database state, stop or coordinate writes for the final cutover, and test reconnection after target failover. Select the target engine version and settings together with the application’s extension and authentication requirements.

​

Compatibility differences

The adapter handles the short-lived client certificate handshake used by Google’s connector libraries and Auth Proxy. Users are created with SQL. Supported extensions and preload libraries differ between the services, so the build identifies requirements RDS cannot provide.

​

On Azure

​

PostgreSQL Flexible Server

Cloud SQL for PostgreSQL becomes an Azure PostgreSQL Flexible Server, and the application keeps the PostgreSQL protocol. Database flags become server parameters.

​

Connection setup and instance changes

The source management API and the database protocol serve different purposes. The adapter creates and configures the target instance and handles the connector certificate exchange; SQL then uses the target engine. Verify the complete connection sequence with the actual client library, including token acquisition and certificate renewal.

​

Moving the database

Provisioning a target instance does not copy data, users, or backup history. Transfer the required database state, stop or coordinate writes for the final cutover, and test reconnection after target failover. Select the target engine version and settings together with the application’s extension and authentication requirements.

​

Compatibility differences

The adapter handles the certificate handshake used by Google’s connector libraries and Auth Proxy. Users are created with SQL, and the target’s allowed extension set still applies.

​

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.