Why Not archive_command?

There’s a significant difference between using archive_command and archiving WAL files via the streaming replication protocol.

The archive_command is triggered only after a WAL file is fully completed-typically when it reaches 16 MiB (the default segment size). This means that in a crash scenario, you could lose up to 16 MiB of data.

You can mitigate this by setting a lower archive_timeout (e.g., 1 minute), but even then, in a worst-case scenario, you risk losing up to 1 minute of data. Also, it’s important to note that PostgreSQL preallocates WAL files to the configured wal_segment_size, so they are created with full size regardless of how much data has been written. (Quote from documentation: It is therefore unwise to set a very short archive_timeout - it will bloat your archive storage.).

In contrast, streaming WAL archiving-when used with replication slots and the synchronous_standby_names parameter-ensures that the system can be restored to the latest committed transaction. This approach provides true zero data loss (RPO=0), making it ideal for high-durability requirements.