If you're tempted to use audit tables, you might also consider making the jump to temporal tables. I rolled my own light-weight version using inheritance-based partitioning in Postgres. The basic idea is:

- Create a parent table like items with a valid time range column as a tstzrange type. This table won't store data.

- Create two child tables using Postgres inheritance, item_past and item_current that will store data.

- Use check constraints to enforce that all active rows are in the current table (by checking that the upper bound of the tstzrange is infinite). Postgres can use check constraints as part of query planning to prune to either the past or current table.

- Use triggers to copy from the current table into the past table on change and set the time range appropriately.

The benefits of this kind of uni-temporal table over audit tables are:

- The schema for the current and past is the same and will remain the same since DDL updates on the parent table propagate to children. I view this as the most substantial benefit since it avoids information loss with hstore or jsonb.

- You can query across all versions of data by querying the parent item table instead of item_current or item_past.

The downsides of temporal tables:

- Foreign keys are much harder on the past table since a row might overlap with multiple rows on the foreign table with different times. I limit my use of foreign keys to only the current table.