Log Shipping

Before Postgres 9.0 introduced streaming replication in 2010, the only way to replicate a Postgres database was to physically copy WAL segment files from the primary to the standby. Fill up a 16MB WAL file, ship it via rsync or scp or NFS, let the standby replay it. Crude? Yes. But it worked, and it has been proven in production for over two decades.

Log shipping has qualities that streaming replication does not. It is dead simple. It is just file copying. You can implement it with a one-line shell script. It works over any network transport, including air-gapped networks where a USB drive is the "network." It does not require a persistent TCP connection between primary and standby. And it naturally creates a disaster recovery archive as a side effect.

SQL Server still uses log shipping as a primary DR mechanism in 2026. Many enterprise shops run it because their DBAs have operated it for 15+ years and trust it implicitly. PostgreSQL shops that need disaster recovery to a remote site (where millisecond lag does not matter, but durability does) still reach for log shipping. pgBackRest, one of the most popular Postgres backup tools, is built entirely around WAL archiving.

You will encounter log shipping in production. Not as the only replication method, but as a complement to streaming replication. The combination of "streaming for HA, archiving for DR" is the standard playbook recommended by every major Postgres consultancy.

The process is straightforward:

1. The primary writes WAL as usual
2. When a WAL segment fills up (16MB), the primary's archive_command fires
3. The archive command copies the completed segment to a shared location (NFS share, S3 bucket, SCP to the standby)
4. The standby periodically checks for new segments in the archive via restore_command
5. When it finds one, it copies it locally and replays it

The key trade-off: The standby is always at least one WAL segment behind the primary. On a busy system writing 16MB of WAL every few seconds, the lag might be seconds. On a quiet system, a single WAL segment might take hours to fill, meaning hours of lag and hours of potential data loss.

Postgres mitigates this with archive_timeout, a setting that forces a WAL segment switch after N seconds, even if the segment is not full. Setting archive_timeout = 60 means the standby is at most 60 seconds behind, even on a database with zero write traffic. The cost is slightly more segment files to archive (partially filled segments).