This is an old idea. It was in the original version of Postgres from Berkeley in the 1980s. They ended up taking it out in 1998 because systems kept running out of disk space:
It's actually very easy to implement if you use the "append" version of MVCC (which Postgres does). All you need to do is just disable garbage collection (e.g., the vacuum).
I have used it in production for years and it works great, but does indeed use a lot of disk space if you enable it for all tables and have many updates.
It's not a full implementation (it lacks the new syntax like `AS OF SYSTEM TIME`) but you can work around that with `UNION` queries and the containment (`@>`) operator.
> It would be interesting to see a list of features from major database management systems that have been removed over the years.
The only other thing I can think of right now are in-memory optimized indexes (e.g., T-Trees) from the 1980s. These were later removed and replaced with B+trees (or skip lists if you're MemSQL) because CPU caches (SRAM) got much faster than memory (DRAM).
it was also in illustra, stonebraker's attempt to commercialize postgres in the 90s.
every table had meta columns defining bounds for validity for this version of a given row. an update copied the row, applied changes, updated validity timestamps on the old and new copies.
aside from the disk space problem you mention, the other issue was that every update required a write to every index on the table, even if the indexed column hadn't been changed. makes simple updates much heavier than one might naively think...
https://www.postgresql.org/docs/6.3/static/c0503.htm
It's actually very easy to implement if you use the "append" version of MVCC (which Postgres does). All you need to do is just disable garbage collection (e.g., the vacuum).