Cascading Read Replicas Now Generally Available!

We’re excited to announce the General Availability of cascading read replicas in Azure Database for PostgreSQL. This capability allows you to create read replicas for your Azure Database for PostgreSQL instance not only from a primary server, but also from existing read replicas, enabling multi‑level replication chains.

Coordinating read‑heavy database workloads across multiple regions can be challenging, especially when you’re trying to deliver low‑latency read response experiences to users spread across different geographic locations. One effective way to address this is by placing read replicas closer to where your users are, allowing applications to serve read requests with significantly reduced latency and improved performance.

What are cascading read replicas?

With cascading read replicas, you can scale read‑intensive workloads more effectively, distribute read traffic efficiently, and support advanced deployment topologies such as globally distributed applications. Each read replica can act as a source for additional replicas, forming a tree‑like replication structure. For example, if your primary server is deployed in one region, you can create direct replicas in nearby regions and then cascade additional replicas to more distant locations. This approach helps spread read traffic evenly while minimizing latency for users around the world. We support up to 2 levels of replication with this feature. Level 1 will be all the read replicas and level 2 will be cascading read replicas.

Why use cascading read replicas?

• Improved scalability
  Cascading read replicas support multi‑level replication, making it easier to handle high volumes of read traffic without overloading a single instance by scaling up to 30 read replicas.
• Geographic distribution
  By placing replicas closer to your global user base, you can significantly reduce read latency and deliver faster, more responsive application experiences.
• Efficient read traffic distribution
  Distributing read workloads across multiple replicas helps balance load, improving overall performance and reliability.

Additionally, cascading read replicas offer operational flexibility. If you observe replication lag, you can perform a switchover operation between a cascading read replica with its source or intermediate replica, helping you maintain optimal performance and availability for your replicas.

How does replication work with cascading read replicas?

The primary server acts as a source for the read replica. Data is asynchronously replicated to these replicas. When we add cascading replicas, the previous replicas act as a data source for replication.

In the diagram above, “primary-production-server” is the primary server with three read replicas. One of these replicas, “readreplica01”, serves as the source for another read replica, “readreplica11” which is a cascading read replica.

With cascading read replicas, you can add up to five read replicas per source and replicate data across two levels, as shown in the diagram. This allows you to create up to 30 read replicas in total five read replicas directly from the primary server, and up to 25 additional replicas at the second level (each second-level replica can have up to five read replicas).

If you notice replication lag between an intermediate read replica and a cascading read replica, you can use a switchover operation to swap “readreplica01” and “readreplica11”, helping reduce the impact of lag.

To learn more about cascading read replicas, please refer to our documentation: Cascading read replicas

Deploying cascading read replicas on Azure portal

1. Navigate to the “Replication” tab and then click on “Create replica” highlighted in red as shown below:
2. After creating a read replica as the below screenshot shows that you have 1 read replica that is attached to the primary instance.
3. Click on the created replica and navigate to the replication tab, source server is “read-replica-01” and we will be creating a cascading read replica under this.

    

4. Once cascading read replica is created you can see the role of “read-replica-01” has now changed to Source, Replica. You can perform site swap operation by clicking on the promote button for cascading read replica.

Deploy cascading read replica with terraform:

Before you start, make sure you have:

• An existing primary PostgreSQL Flexible Server
• At least one read replica already created from the primary
• AzureRM provider with latest version
• Proper permissions on the Azure subscription and resource group

1. Configure the AzureRM Provider: Start by configuring the AzureRM provider in your Terraform project.

   terraform {
     required_providers {
       azurerm = {
         source  = "hashicorp/azurerm"
         version = "~> 3.80"
       }
     }
   }
   
   provider "azurerm" {
     features {}
   }

2. Reference the existing read replica server using the data block to reference the replica server.

   data "azurerm_postgresql_flexible_server" "source_replica" {
     name                = "my-read-replica-1"
     resource_group_name = "my-resource-group"
   }

3. Now create a new PostgreSQL Flexible Server and point it to the replica using create_source_server_id.

   resource "azurerm_postgresql_flexible_server" "cascading_replica" {
     name                   = "my-cascading-replica"
     resource_group_name    = "my-resource-group"
     location               = data.azurerm_postgresql_flexible_server.source_replica.location
     version                = data.azurerm_postgresql_flexible_server.source_replica.version
   
     delegated_subnet_id    = data.azurerm_postgresql_flexible_server.source_replica.delegated_subnet_id
     private_dns_zone_id    = data.azurerm_postgresql_flexible_server.source_replica.private_dns_zone_id
   
     create_mode            = "Replica"
     create_source_server_id = data.azurerm_postgresql_flexible_server.source_replica.id
   
     storage_mb             = 32768
     sku_name               = "Standard_D4s_v3"
   
     depends_on = [
       data.azurerm_postgresql_flexible_server.source_replica
     ]
   }

4. Apply the Terraform Configuration

   terraform init
   terraform plan
   terraform apply

    

Key Considerations

1. Cascading read replicas allow for up to 5 read replicas and two levels of replication.
2. Creating cascading read replicas is supported in PostgreSQL version 14 and above.
3. Promote operation is not supported for intermediate read replicas with cascading read replicas.

Conclusion

Cascading read replicas in Azure Database for PostgreSQL offer a scalable way to distribute your read traffic across the same and different regions, reducing the read workload on primary database. For globally distributed applications, this can improve read latency as well as resilience and performance. This design supports horizontal scaling as your application demand grows, ensuring you can handle a high volume of read requests without compromising speed. Get started with this feature today and scale your read workloads.