temporal_tables VS pgreplay

It was reimplemented in pure SQL here https://github.com/nearform/temporal_tables for this purpose

I enjoyed this blog. I think it provides a great succinct overview of various approaches native to Postgres.

For the "capture changes in an audit table" section, I've had good experiences at a previous company with the Temporal Tables pattern. Unlike other major RDBMS vendors, it's not built into Postgres itself, but there's a simple pattern [1] you can leverage with a SQL function.

This allows you to see a table's state as of a specific point in time. Some sample use cases:

- "What was this user's configuration on Aug 12?"

- "How many records were unprocessed at 11:55pm last night?"

- "Show me the diff on feature flags between now and a week ago"

[1]: https://github.com/nearform/temporal_tables

One of these Postgres-based implementations of SQL:2011's temporal versioning features might get you close enough:

- https://github.com/nearform/temporal_tables

You don't really need to install an extension to use temporal tables, there is an alternative (https://github.com/nearform/temporal_tables) implemented purely as a plpgsql trigger so that it works everywhere.

I was part of a team at NearForm using this for a project on an EC2 instance. In order to move to AWS RDS we had to recreate the functionality of temporal_tables as a PostgreSQL function, rather than extension.

When we switched, we found that although there were minor bugs, we didn't have any noticeable loss of performance and we have used it ever since for many projects.

https://github.com/nearform/temporal_tables

If you're also limited by cloud services and the extensions limitations, this is a great solution.

pgreplay parses not the WAL Write Ahead Log but the log file: https://github.com/laurenz/pgreplay

From "A PostgreSQL Docker container that automatically upgrades your database" (2023) https://news.ycombinator.com/item?id=36748041 :

pgkit wraps Postgres PITR backup and recovery:

This blog was just to verify that it works with YugabyteDB. Check pgreplay documentation for more, all works the same in YugabyteDB. If you want to capture a workload from connections on multiple database nodes, each one will have their logfile. You can merge them. The Session ID (the 6th field in the csvlog built from start time and backend pid will probably not collide with another one, but you can make it unique by concatenating a node number if you want). The replay connects to one node, but though a HA proxy the connections can be distributed to multiple ones. All depends on what you want to capture and wh you want to replay. Capturing from PostgreSQL and replaying to YugabyteDB is also a good way to check that all works the same without performance regressions.