Modeling State Transitions in Postgres

On most projects I’ve consulted on, status starts as a column. It works, until someone asks “who was denied last Tuesday?” and the schema can’t answer. At that point, you can’t retrofit history you never recorded. There’s a better way: model each status change as its own row from the start. You get full history and the current state in one design, without sacrificing read performance. Here’s how. Say we have a users table with name and status columns: id name status 1 Paul Winston pending 2 B...