I was calling the WAL the "queries" to simply, never mind that, it doesn't matter whether it contains the queries or not. What's important is that the WAL was

I was calling the WAL the "queries" to simply, never mind that, it doesn't matter whether it contains the queries or not. What's important is that the WAL was generated on a periodic basis and of a constant size. Say 16MB every minute. It's pretty much a plain file, that could be stored on S3/FTP. This had a lot of drawbacks: - Replicas were measurably late behind the current state, simply because of the built-in delay in "replication". - It was incredibly inefficient on bandwidth and storage. Consider the time it takes to transfer large files (especially for off-site replicas) and storage costs. That further contributed to poor performance and delay. - There could be many WAL files generated at once when there were changes happening. They would take FOREVER to be processed. It was commonplace for replicas to fall 5-10 minutes under what I consider to be minimum activity. Long story short, the replication was reworked in a later version of PostgreSQL (3 or 4 years ago), the part about fixed size and fixed delay is not true anymore.