A standby accepts connections, and the lag graph looks calm—but neither proves that it can safely take production writes.
Fastest safe decision: Do not approve PostgreSQL 18 primary-standby replication based only on lag or reachability. Verify WAL receipt and replay, rehearse a controlled promotion, test application writes, inspect any logical replication slots, and confirm the rollback boundary. Asynchronous replication can lose transactions that have not reached the standby; replication is not a substitute for an off-host backup.
Suitable: Teams preparing a PostgreSQL 18 primary and physical standby for production release.
Not suitable: Teams looking for a general replication setup tutorial or an automatic failover service.
DBAs need evidence that replication and promotion work as expected.
Infrastructure engineers need to check server resources, network paths, access controls, and node isolation.
Application and on-call teams need to verify reconnection, write behavior, and release approval conditions.
PostgreSQL 18 primary-standby replication acceptance starts with evidence
A useful acceptance record separates three states that are often collapsed into one dashboard number:
- Connected: the primary and standby can communicate.
- Received: the standby has received WAL from the primary.
- Replayed: the standby has applied that WAL and can serve a state that includes it.
On the primary, inspect pg_stat_replication, including the sender state and the WAL positions reported for the connected standby. On the standby, inspect pg_stat_wal_receiver and compare the receive and replay positions. PostgreSQL’s streaming replication monitoring documentation describes the relevant views and positions. The administrative functions reference documents functions that can help check recovery and WAL progress.
A connected sender does not prove that replay is current. A standby that is reachable over the network does not prove it is ready to become the writer. The acceptance record should preserve the outputs from both sides, the time of each observation, and the interpretation agreed by the DBA.
Reminder: A lag value is a snapshot, not a guarantee about what will be present on the standby at the instant the primary fails.
The PostgreSQL version policy gives major releases a five-year support period. That is a reason to plan maintenance against the installed major and minor release, not a reason to assume that replication behavior or a failover procedure has been tested for a specific deployment.
DBA checks: separate healthy streaming from recoverable WAL
Before the rehearsal, verify that the expected standby is connected and that its receive and replay positions progress when the primary generates WAL. Use the PostgreSQL 18 monitoring views rather than a single lag alert. Record any persistent difference between receipt and replay; a standby can receive WAL while still being behind in applying it.
Then check replication-slot state on the primary. Slots can retain WAL needed by a consumer, but a slot that stops advancing can also create WAL-retention pressure. The PostgreSQL 18 replication slot view reference documents fields such as restart_lsn and wal_status. In particular, the documented wal_status values distinguish states including reserved, extended, unreserved, and lost; do not treat every existing slot as proof that the required WAL remains available.
Review the settings that define the intended behavior, including synchronous_standby_names, synchronous_commit, and the replication connection and retention settings. PostgreSQL documents these in its replication configuration reference. The acceptance record should state whether the deployment is asynchronous or synchronous and what that means for acknowledged writes during failover.
With asynchronous replication, a transaction acknowledged by the primary may not yet have reached the standby when the primary becomes unavailable. The possible data gap depends on what was sent and replayed at the time of failure. Do not publish a fixed loss estimate or call the setup lossless unless the deployment’s configuration and tests support that claim.
Infrastructure checks: confirm the boundary between the nodes
The infrastructure owner should document the actual path between primary and standby, including routing, firewall rules, name resolution, and access control. Test the same path used by PostgreSQL rather than assuming that general host reachability proves the database connection is reliable. Confirm how each node is isolated if the primary becomes unreachable but has not actually stopped.
| Acceptance area | Planned drill | Unplanned failure |
|---|---|---|
| Node state | Confirm which node is primary and which is in recovery before the test | Determine whether the old primary is stopped, isolated, or still able to accept writes |
| Promotion authority | Identify the operator and the approved promotion action | Follow the documented decision path; do not promote solely because a health check failed |
| Client routing | Verify how clients reach the intended writer | Confirm that clients cannot keep writing to the former primary |
| Data boundary | Record receive and replay positions before promotion | State what data may be absent if asynchronous WAL had not reached the standby |
| Exit condition | Stop the drill if role or write checks fail | Prevent both nodes from acting as independent writers |
A bare-metal plan should also match the server resources and system actually selected for each node. Do not copy a sample CPU, memory, disk, bandwidth, or operating-system configuration into an acceptance record as if it were guaranteed for every order. Verify those details against the current SFP Cloud server overview and its published pricing and options. Neither a server rental nor two separately provisioned machines establishes a private network, automated failover, or managed cluster unless the service documentation explicitly says so.
If the selected server has no hardware RAID, the database team must choose an appropriate software RAID or replication design and test it. Neither RAID nor primary-standby replication replaces a backup stored outside the database host.
DBA drill: promote the standby without creating two writers
Use a planned, controlled rehearsal in an environment where the team can safely manage both nodes. PostgreSQL’s standby promotion guidance describes the relevant failover behavior. The promotion function is documented as pg_promote() in the administrative functions reference; invoking it is a manual promotion action, not an automatic failover system.
Before promotion:
- Record the roles reported by the primary and standby.
- Capture the primary’s sender state and the standby’s receive and replay positions.
- Confirm the operator, the stop conditions, and the method for preventing the old primary from accepting writes.
- Tell the application and on-call owners when the drill starts and what outcome will end it.
Promote the standby only under the approved drill plan. Then confirm that it has left recovery, is the intended writer, and accepts a reversible test transaction. Record the role change and the order of events. A database port accepting connections is not enough: the promoted node must accept the expected writes, and the application must be able to reach it through its normal connection path.
Do not bring the old primary back as a writer without first handling its divergent state. Fence or stop it as required by the recovery plan, then rejoin it using a procedure that prevents split brain and accounts for WAL divergence. If the team has no tested rejoin procedure, the drill has exposed an unresolved production risk rather than passed the acceptance check.
Application checks: prove that business writes recover
The application owner should test the full path from client to database, not just a command-line connection from an administrator’s workstation. In particular, review connection-pool behavior, stale connection handling, DNS or endpoint changes, transaction retries, and how the application reports uncertain outcomes.
Use a reversible test transaction with a clear expected result. Verify that the application sends the write to the promoted primary and can read the result through its normal path. Also check that a disconnected client does not blindly retry a non-idempotent operation when the original transaction may have committed before the connection failed.
The acceptance record should distinguish:
- Database promotion completed.
- The application connected to the intended writer.
- A test write completed and was read back.
- The application handled an uncertain or interrupted transaction according to its retry policy.
- The former primary could not receive competing writes.
These are separate checks. A successful database promotion does not prove that the application has recovered, and a healthy application connection does not prove that the old primary has been fenced.
Downstream data checks: treat logical slots as a separate dependency
Physical streaming replication and logical replication serve different purposes. A physical standby replays WAL for a database cluster; logical subscribers and CDC consumers depend on logical replication publications and slots. A healthy physical standby therefore does not, by itself, prove that every downstream consumer can continue after promotion.
Inventory each logical subscriber and slot-dependent consumer. If logical replication is in use, check the slot state and the failover configuration against the PostgreSQL 18 logical replication overview and logical replication failover guidance. Confirm that the documented synchronization requirements are satisfied before relying on a slot after role change. If no logical replication or slot-dependent consumer exists, mark the check “not applicable” and identify who confirmed that inventory.
| Owner | Evidence to attach | Release decision |
|---|---|---|
| DBA | Sender and receiver state, WAL positions, slot inventory, and promotion record | Stop release if replay, slot state, or role is unexplained |
| Infrastructure | Network path, access rules, node-isolation method, and server details checked against the order | Stop release if both nodes could remain writable or the standby path is unverified |
| Application | Connection recovery, reversible write result, retry behavior, and endpoint recognition | Stop release if writes can go to the former primary or uncertain transactions are retried unsafely |
| Downstream data | Subscriber and CDC inventory, slot checks, or a signed not-applicable record | Stop release if a required consumer cannot resume as documented |
| On-call lead | Named decision owner, stop conditions, rollback boundary, and drill timeline | Approve only when owners agree on the data-loss and recovery limits |
On-call sign-off: keep failover, rollback, and backup distinct
The on-call lead should collect the evidence from each owner and make the release decision explicit. Record who may authorize promotion, who can isolate the old primary, what observation stops the drill, and how the team will restore the intended topology if the test fails. If the team cannot prevent two writable primaries, do not turn a connectivity alarm into a promotion decision.
Finally, test recovery from an off-host backup. PostgreSQL’s backup and restore documentation covers backup and recovery approaches. Confirm that the backup is stored outside the database host, that the required recovery materials are available, and that a restore procedure has been exercised. Replication can copy a mistaken deletion or corrupted change; it is not an independent recovery point.
FAQ: resolve the remaining promotion questions
How do I know a PostgreSQL 18 standby is ready to promote?
Check the primary’s sender state and WAL positions, then confirm that the standby’s receiver is connected and replay is advancing. Those checks establish replication health, not production readiness by themselves. A controlled promotion drill must also prove that the promoted node accepts the intended writes, clients reconnect correctly, and the old primary cannot resume as a competing writer.
Is low PostgreSQL replication lag enough to approve a failover?
No. A low lag reading is only a momentary view, and asynchronous replication can leave transactions that were committed on the primary but had not reached the standby. Review receive and replay positions, understand the data-loss boundary your team accepts, and rehearse promotion and application recovery before treating the standby as an approved failover target.
What should the application team verify after PostgreSQL fails over?
Confirm that the connection pool abandons stale connections, discovers the new write endpoint, and retries only operations whose outcome is known to be safe. Test a reversible write and read it from the promoted primary. Also record how the client avoids sending writes to the former primary and how the team handles a transaction whose result was uncertain during disconnect.
Will PostgreSQL 18 logical replication slots remain usable after the primary changes?
Do not assume so. Physical streaming replication and logical replication have different slot requirements. Inventory every logical subscriber and CDC consumer, then verify that the PostgreSQL 18 failover-slot configuration and synchronization state meet the documented conditions. If the system does not use logical slots, record that as not applicable rather than marking an untested check as passed.
Choose infrastructure only after the acceptance design is clear
A server rental can provide dedicated hardware, but it does not supply a verified primary-standby topology, automatic promotion, or a tested recovery plan by itself. Shared instances may also constrain CPU consistency, disk layout, and control over the operating system; weigh those limits against the operational work of managing replication, failover, and off-host backups.
For a database expected to run continuously on dedicated resources, compare the target memory, directly attached NVMe layout, supported operating system, and billing period against the current SFP Cloud product listing before choosing a server. The team still needs to design and test the replication path, node isolation, promotion, slot handling, and backup recovery. If that ownership is not available—or the workload is temporary and lightly loaded—a managed database or shared instance may be the more appropriate choice.
FAQ
-
Q
How can I tell whether a PostgreSQL 18 standby is ready to promote?
Check the primary's sender state and WAL positions, then confirm on the standby that the receiver is connected and replay is advancing. Those checks establish replication health, not production readiness by themselves. A controlled promotion drill must also prove that the promoted node accepts the intended writes, clients reconnect correctly, and the old primary cannot resume as a competing writer.
-
Q
Is low PostgreSQL replication lag enough to approve a failover?
No. A low lag reading is only a momentary view, and asynchronous replication can leave transactions that were committed on the primary but had not reached the standby. Review receive and replay positions, understand the data-loss boundary your team accepts, and rehearse promotion and application recovery before treating the standby as an approved failover target.
-
Q
What should the application team verify after PostgreSQL fails over?
Confirm that the connection pool abandons stale connections, discovers the new write endpoint, and retries only operations whose outcome is known to be safe. Test a reversible write and read it from the promoted primary. Also record how the client avoids sending writes to the former primary and how the team handles a transaction whose result was uncertain during disconnect.
-
Q
Will PostgreSQL 18 logical replication slots remain usable after the primary changes?
Do not assume so. Physical streaming replication and logical replication have different slot requirements. Inventory every logical subscriber and CDC consumer, then verify that the PostgreSQL 18 failover-slot configuration and synchronization state meet the documented conditions. If the system does not use logical slots, record that as not applicable rather than marking an untested check as passed.
Build Your PostgreSQL Failover Setup on Dedicated Hardware
Deploy your PostgreSQL primary or standby on an AMD EPYC 7543P with 32 cores and 64 threads. The servers are in Tokyo, Japan. You can order before you sign in.