Managing read replicas
The Read replicas page gives you two views, toggled with the Flow and Table controls in the top-right corner. The Flow view displays the replication topology — your primary instance at the top with arrows flowing down to each attached replica, showing tier, region, and status at a glance: The Table view lists each replica with its service name, cloud provider and region, service status, creation time, and a Detach service action: To create a new replica, click Create read replica in the top-right corner of either view.Why use read replicas
Scalability
Read replicas allow you to scale your database horizontally by distributing read-heavy workloads across multiple dedicated instances. This is particularly valuable for reporting queries, analytics processing, and real-time dashboards that would otherwise compete with your production traffic for resources.Isolation
By directing analytical and business intelligence queries to read replicas, you keep your primary instance focused and responsive for write operations and critical transactional workloads. This separation improves overall system performance and predictability. It also means you don’t need to grant write access to analytical or reporting tools—they can operate safely against a replica with no risk of accidental data modification.Business continuity
Read replicas can play a critical role in disaster recovery. If your primary database fails, a read replica can be promoted to primary, minimizing downtime and data loss. This provides an additional layer of resilience beyond your high availability standbys.How read replicas work
By default, read replicas in ClickHouse Managed Postgres use a WAL shipping architecture rather than streaming replication. This design choice prioritizes minimizing impact on your primary database.WAL shipping from object storage
When your primary database processes transactions, it generates Write-Ahead Log (WAL) records. These WAL segments are continuously archived to object storage. Read replicas fetch and replay these WAL segments from object storage to stay synchronized with the primary. This architecture differs from high availability standbys, which use streaming replication with a direct connection to the primary.Why we chose this approach
We intentionally designed read replicas to consume WAL from object storage rather than connecting directly to the primary as streaming standbys. This approach provides complete isolation between read replicas and your primary database:- Zero replication overhead on primary: Read replicas don’t maintain streaming connections to the primary, so they add no CPU, memory, or network load to your mission-critical workloads.
- Independent scaling: You can add or remove read replicas without any impact on primary performance.
- Network isolation: Read replicas operate in their own network environment with separate connection endpoints.
Replication lag characteristics
By default, the primary ships changes to replicas whenever a 16 MB WAL segment fills or 60 seconds pass, whichever comes first. On a busy primary, writing several MB per second, replication lag is typically a few seconds. On a quiet primary, lag can approach 60 seconds, which can lead to unexpected results in testing and low-throughput environments. Long-running queries on a replica can also add lag. When a query conflicts with changes from the primary, replay pauses for up to 30 seconds so the query can finish. For most read scaling use cases—reporting, analytics, dashboards—this lag is acceptable. If your use case needs shorter or more predictable lag, there are two options:- Tuning WAL shipping. In most use cases, lowering
archive_timeoutandwal_retrieve_retry_intervalbrings lag to 1–3 seconds. The cost is somewhat more network and storage activity, and larger backups. Contact support to change these settings. - Streaming replication. For sub-second requirements, streaming brings lag down to roughly 10–20 ms. This comes at the cost of increased network usage and CPU load on the primary, and may increase maintenance overhead. It also breaks the isolation between the primary and read replicas that WAL shipping provides: long-running queries on the replica can hold back
VACUUMand cause bloat on the primary. If your application needs this, open a support request and we’ll help confirm it’s the right fit and set it up.