PostgreSQL
PostgreSQL cluster deployment
Read replicas via streaming replication, a failover scenario and scheduled backups. Replication traffic runs over the 10 Gbps isolated private network.
- Replication method
- Streaming
- Query load distribution
- Read replica
- Point-in-time recovery
- PITR
- Low-latency data disk
- NVMe
The question to answer before building a cluster
There are two distinct reasons to build a PostgreSQL cluster, and they lead to different architectures. The first is distributing read load: when reporting queries strain the primary, a read replica is created and heavy queries are directed there. The second is high availability: keeping the service running when the primary fails.
Both use the same technology but require different configuration. For read distribution, asynchronous replication is usually enough — a replica lagging a few seconds is fine for reporting. For high availability, your tolerance for data loss may demand synchronous replication, which costs write performance.
Replication lag depends directly on network quality. Carrying replica traffic over the 10 Gbps isolated private network is a clear advantage over setups that use internet egress, because synchronisation lag is unaffected by external traffic.
On the backup side, point-in-time recovery can be configured. That makes requests like "restore to yesterday at 14:30" possible — the capability most needed after an accidental delete statement.
- Read replicas move reporting load off the primary
- A failover scenario is designed for high availability
- Replication traffic runs on the isolated private network
- PITR restores to a specific point in time
- Connection pooling and memory settings tuned to the workload
Features
Components configured
Streaming replication
Changes on the primary stream continuously to the replica; lag is monitored and alerts on threshold breach.
Read replica routing
Reporting and analytics queries are directed to the replica, preserving the primary's transaction capacity.
Point-in-time recovery
WAL archiving enables restoring to a specific moment — critical after an accidental deletion.
Connection pooling
For applications opening many short-lived connections, pooling markedly reduces memory consumption.
Query monitoring
Slow queries, lock waits and cache hit ratio are tracked so performance problems surface early.
Access restriction
The database is reachable only from the application segment and never exposed directly to the internet.
FAQ
Frequently asked questions
How far behind does a read replica run?
With asynchronous replication, lag is usually sub-second and can grow somewhat under heavy writes. Lag is monitored continuously and alerts when it exceeds the agreed threshold. For reporting scenarios that level of lag is not a problem.
What happens if the primary fails?
A failover scenario is designed in advance: under what conditions the replica takes over, how the application discovers the new address and how failback is performed are all documented. Without these steps defined, outage duration is set by improvisation rather than decision.
Should I choose synchronous or asynchronous replication?
It depends on your tolerance for data loss. With synchronous replication a write does not complete until the replica acknowledges it, minimising loss risk at the cost of write latency. Asynchronous writes are faster, but a sudden failure may lose the last few transactions. We make the call together based on your business requirements.
More
Related pages
- Managed DatabasesManaged database servicesManaged database services covering deployment, configuration, backup, monitoring and version management. NVMe storage with replication over a 10 Gbps private network.
- MySQL / MariaDBMySQL and MariaDB hostingManaged MySQL / MariaDB hosting with InnoDB tuning, connection pooling, utf8mb4 configuration and master-replica setup. NVMe storage and daily backups.
- High AvailabilityHigh availability (HA) architectureHA architectures with single points of failure removed: per-component redundancy, a defined failover scenario and regular rehearsals.
Let's plan your infrastructure together
Tell us what you need and we prepare a configuration and pricing specific to you. We don't sell fixed packages; we build the deployment, licensing and backup plan with you.