But what is a transaction error? <UPDATE user_profiles SET first_name = 'REDACTED';> will execute very successfully from the databases point of view.. And from

But what is a transaction error? <UPDATE user_profiles SET first_name = 'REDACTED';> will execute very successfully from the databases point of view.. And from a business point of view, it might be either a horrible thing (in production), or a thing that happens every saturday (on dev). But, beyond that, our Postgres + PGBackrest setup could do point in time recovery. It would be a pain, because you'd have to dig through lots and lots of WAL archives with some pg-wal-viewer to figure out the exact transaction that started to cause damage. And then you could reset the database to the exact transaction before that. Except, this is weaker than the audit logs presented in the article. If there was a mix of poison changes and valid transactions after the identified point, we'd lose the valid changes after the first poison transaction. That may have some amount of impact which has to be evaluated from a business sense. But, keeping these detailed audit logs around for busy tables isn't an option. If you dump a couple hundred records per second into a table, it's not really a good idea to double the write load with trigger inserts into a second table. That can incur a pretty significant increase in hardware cost to host the dang thing. But eh, I'd much rather implement this as an append table with a bit of smart indexing. Annotate the shard routing with a <valid_since> and select <ORDER BY valid_since DESC LIMIT 1>. This way, you wouldn't need two tables, and you could rollback a bad update either with a <DELETE FROM routing WHERE valid_since BETWEEN ...>, or updating them into the past.