Skip to content

Managed PostgreSQL DR with Cloud SQL

Overview

Managed PostgreSQL DR with Cloud SQL is the managed recovery path for PostgreSQL. The primary database stays on-prem until promotion is approved, while Cloud SQL provides a replication-ready recovery lane through Database Migration Service.

It suits teams that want a cloud recovery option with a managed database target and explicit promotion and return controls.

Case study

  • Context: the on-prem PostgreSQL HA estate needed a tested cloud recovery option while avoiding the day-to-day operation of a second self-managed HA estate in GCP.
  • Challenge: cloud recovery capacity had to remain replication-ready, and both promotion and failback had to remain under explicit operator control.
  • Approach: org/gcp/cloudsql-external-replica establishes Database Migration Service source and destination connection profiles plus a logical-replication migration job into Cloud SQL. Promotion is a discrete operator action. Return on-prem follows dr/postgresql-cloudsql-failback-onprem@v1 as a separate controlled step.
  • Outcome: the recorded drill established the managed standby, exercised the promotion path, completed isolated failback, and returned the service position to the on-prem lane with DNS confirmation.

Covers Cloud SQL external replica setup, controlled promotion, failback on-prem, and final DNS confirmation after the recovery drill.

Outcome

The recovery lane keeps a managed standby ready while preserving explicit control over service-position changes.

  • The authoritative write source remains on-prem until promotion is approved.
  • Database Migration Service maintains the logical-replication path into the Cloud SQL recovery target.
  • Promotion moves the active service position to Cloud SQL through a separate control gate.
  • Failback prepares and verifies the on-prem service before DNS returns.

Operating model

  • On-prem PostgreSQL HA stays the live write source in normal operation.
  • Database Migration Service maintains logical replication into the managed Cloud SQL recovery target.
  • Promotion is explicit and controlled.
  • Return on-prem is a separate controlled step with its own service-position verification.

Compared with the self-managed HA recovery cycle, this lane uses a managed recovery target rather than recreating a second Patroni estate.

Architecture

Managed PostgreSQL DR architecture showing the on-prem write source, Database Migration Service logical replication, Cloud SQL managed standby, explicit promotion gate, managed primary position, isolated failback lane, and final on-prem service-position verification.

Database Migration Service maintains the logical-replication path from the on-prem source to the managed Cloud SQL standby. Promotion and failback are separate operator gates: promotion moves the active service position to Cloud SQL, while the isolated return lane restores and verifies the on-prem service before DNS returns.

Recovery sequence

  1. The on-prem source posture is assessed and Database Migration Service establishes the managed standby path.
  2. Logical replication keeps the Cloud SQL target recovery-ready.
  3. Promotion moves service position to Cloud SQL through an explicit operator action.
  4. Service returns on-prem through an isolated failback path.
  5. DNS and final service position are checked after the return.

Platform state

Cloud SQL instances list from the recorded drill, showing the source instance, external primary contract, and managed standby together
External-primary contract and managed standby visible together.
Recorded gcloud Cloud SQL standby describe output from the drill window, showing the standby instance name, region, state, activation policy, and private address
Standby region, state, activation policy, and private address.
Cloud SQL standby overview for hyops-dev-netbox-standby1, showing the managed standby posture and data-transfer view from the drill window
Managed standby posture and replication activity during the drill.

IP addresses, hostnames, and instance identifiers visible in screenshots and recordings reflect the ephemeral infrastructure provisioned during the recorded exercise.

Where it fits

  • when a managed PostgreSQL recovery target is preferred to operating a second self-managed HA estate
  • when the normal write source remains on-prem but cloud recovery must stay replication-ready
  • when promotion and return need separate, reviewable operating gates

Implementation

  • Source assessment: platform/onprem/postgresql-dr-source checks the on-prem estate before any standby operation begins.
  • Managed standby: org/gcp/cloudsql-external-replica establishes the Database Migration Service logical-replication path and managed target.
  • Promotion path: promotion remains a discrete step requiring explicit operator approval.
  • Failback path: dr/postgresql-cloudsql-failback-onprem@v1 returns the service on-prem as a separate controlled operation.
  • DNS layer: platform/network/dns-routing manages the cutover record at each stage.

Key components

  • Source posture and assessment: platform/onprem/postgresql-dr-source
  • Managed standby path: org/gcp/cloudsql-external-replica
  • Promote workflow: dr/postgresql-cloudsql-promote-gcp@v1
  • Controlled return workflow: dr/postgresql-cloudsql-failback-onprem@v1
  • DNS cutover layer: platform/network/dns-routing

References

Further reading
Implementation references
  • platform/onprem/postgresql-dr-source
  • org/gcp/cloudsql-external-replica#managed_standby
  • platform/network/dns-routing#postgresql_dns_status_cloudsql_failback_onprem

What was verified

Verified during the recorded HybridOps v1.0.1 managed standby drill with the standby established, the controlled promotion path tested, and the isolated failback drill completed.