State persistence
Keep only the current value of each record, and overwrite it in place whenever it changes.
How they work
Most applications store the latest state of their data in a database and insert or update rows as things change: the create, read, update and delete (CRUD) model. An UPDATE replaces the old value, so the row always answers “what is true now?” with a single lookup. It is simple and fast for most workloads, and every read sees the latest committed write.
What it drops is history. The database holds only the latest state, so unless you add an audit mechanism you can’t say what a value was last week or why it changed. A common fix is a trigger that copies every insert, update and delete into an audit table, stamped with the time and user; PostgreSQL’s documentation shows one. Updating rows in place also takes row locks, which can contend under heavy write load. When the past matters as much as the present, look at bitemporal tables or event sourcing.