About replication in Cloud SQL

Replication is the ability to create copies of a Cloud SQL instance or an on-premises database, and offload work to the copies.


The primary reason for using replication is to scale the use of data in a database without degrading performance.

Other reasons include:

  • Migrating data between regions
  • Migrating data between platforms
  • Migrating data from an on-premises database to Cloud SQL

Additionally, a replica could be promoted if the original instance becomes corrupted.

When referring to a Cloud SQL instance, the instance that is replicated is called the primary instance and the copies are called read replicas. The primary instance and read replicas all reside in Cloud SQL.

When referring to an on-premises database, the replication scenario is called replicating from an external server. In this scenario, the database that is replicated is the source database server. The copies that reside in Cloud SQL are called Cloud SQL replicas. There is also an instance that represents the source database server in Cloud SQL called the source representation instance.

You can also use the Database Migration Service for continuous replication from a source database server to Cloud SQL.

Cloud SQL supports the following types of replicas:

Cloud SQL does not support replication between two external servers.

Read replicas

You use a read replica to offload work from a Cloud SQL instance. The read replica is an exact copy of the primary instance. Data and other changes on the primary instance are updated in almost real time on the read replica.

Read replicas are read-only; you cannot write to them. The read replica processes queries, read requests, and analytics traffic, thus reducing the load on the primary instance.

You connect to a replica directly using its connection name and IP address. If you're connecting to a replica using a private IP address, you don't need to create an additional VPC private connection for the replica as it is inherited from the primary instance.

For information about how to create a read replica, see Creating read replicas. For information about managing a read replica, see Managing read replicas.

As a best practice, put read replicas in a different zone than the primary instance when you use HA on your primary instance. This practice ensures that read replicas continue to operate when the zone that contains the primary instance has an outage. See the Overview of high availability for more information.

Cross-region read replicas

Cross-region replication lets you create a read replica in a different region from the primary instance. You create a cross-region read replica the same way as you create an in-region replica.

Cross-region replicas:

  • Improve read performance by making replicas available closer to your application's region.
  • Provide additional disaster recovery capability to guard against a regional failure.
  • Let you migrate data from one region to another.

See Promoting replicas for regional migration or disaster recovery for more information about cross-region replicas.

Logical replication

Cloud SQL enables you to configure your own replication solutions by using PostgreSQL's logical replication features. Logical replication is a flexible solution allowing:

  • Standard replication from a primary instance to a replica
  • Selective replication of only certain tables or rows
  • Replication across PostgreSQL major versions
  • Replication to non-PostgreSQL databases
  • Change data capture (CDC) workflows where all database changes are streamed to a consumer

For more information, see Setting up logical replication. That page includes information about:

  • Native logical replication
  • The pglogical extension

Replication use cases

The following use cases apply for each type of replication.

Name Primary Replica Benefits and use cases More information
Read replica Cloud SQL instance Cloud SQL instance
  • Additional read capacity
  • Analytics target
Cross-region read replica Cloud SQL instance Cloud SQL instance
  • Additional read capacity
  • Analytics target
  • Additional disaster recovery capability
  • Improve read performance
  • Migrate data between regions
Logical replication Any PostgreSQL instance Any PostgreSQL instance, or an external consumer
  • Replication from outside of Cloud SQL
  • Replication across PostgreSQL versions
  • Replicating only a subset of data in some tables, using row and column filtering. Also see pglogical 2.1 and Logical Replication in PostgreSQL 10.
  • Replication to non-PostgreSQL destinations (change data capture)


  • A read replica is charged at the same rate as a standard Cloud SQL instance. There is no charge for the data replication.
  • Because a replica always maintains a connection to its primary, the primary instance is never deactivated. This scenario could result in a billing increase for the primary instance. Learn more.
  • In addition to the regular cost associated with any Cloud SQL instances, a cross-region replica incurs cross-region network egress charges for replication logs sent from the primary to the replica, as described in Network Egress Pricing.
  • Pricing for a cross-region read replica is the same as for creating a new instance in the region. Refer to Cloud SQL instance pricing and select the appropriate region.

Quick reference for Cloud SQL read replicas

Topic Discussion
High availability Read replicas neither provide high availability nor offer it.
Failover A primary instance cannot failover to a read replica, and read replicas are unable to failover in any way during an outage.
Maintenance windows Maintenance windows cannot be set on read replicas and they do not share maintenance windows with the primary instance. Maintenance can occur at any time on the read replica. Maintenance occurs on read replicas at a different time than on the primary instance.
Disruptive upgrades Read replicas can experience a disruptive upgrade at any time.
Multiple read replicas You can create up to 10 read replicas for a single primary instance.
Load balancing Cloud SQL does not provide load balancing between replicas. Use connection pooling and distribute queries across replicas.
Settings The settings of the primary instance are propagated to the replica, including the password for the postgres user and changes to the user table.
Cores and memory Read replicas can use a different number of cores and amount of memory from those of the primary instance. PostgreSQL read replicas can have more CPUs and memory than the primary instance, but they cannot have fewer spCPUs or less memory.
User tables You cannot make changes on the replica. All user changes must be done on the primary instance.
Backups You cannot configure backups on the replica.
Restoring the primary instance You cannot restore the primary of a replica while the replica exists. Before restoring an instance from a backup, or performing a point-in-time recovery on it, you must promote or delete all of its replicas.
Deleting the primary instance Before you can delete a primary instance, you must promote all of its read replicas to stand-alone instances or delete the read replicas.
Disabling write-ahead logging Before you can disable write-ahead logs on a primary instance, you must promote or delete all of its read replicas.
Creating a replica of a replica You cannot create a replica of a replica.
Stopping a replica You cannot stop a replica. You can restart, delete, or disable replication on it, but you cannot stop it as you can a primary instance.
Private IP If you're connecting to a replica using a private IP address, you don't need to create an additional VPC private connection for the replica, as it is inherited from the primary instance.

What's next