alt Hacker NewsSome kind of versioning is extremely important for certain use cases. And having it a core DB feature makes it easier to show that you implement that checkbox.
One thing I'm wondering about is the performance of temporal tables for the common case, when you only query current rows. When you manually version tables, one strategy is to have a second table that contains archived versions. So your main table only has the current rows, avoiding a performance hit for having many versions per entry. Is there a way to do this with temporal tables? For example partitioning between active and old rows?
For application time, everything lives in one table (although you could partition it). The biggest performance hit, I suspect, will come from GiST indexes instead of B-Trees. Some general GiST improvements are on my TODO list, and I learned at PGConf.dev that several other people already have patches for cool perf-related GiST enhancements.
For system time, a separate history table is a common implementation, sometimes also with partitioning. Here is what other vendors are doing: https://illuminatedcomputing.com/posts/2019/08/sql2011-surve...