Crux timestamps sit outside of the data model and apply universally across the whole database (the data model is documents not tables), so you don't have to con

Crux timestamps sit outside of the data model and apply universally across the whole database (the data model is documents not tables), so you don't have to consciously think about managing bitemporality at all by default, but whenever you might need it, it's there. This means you don't have to adapt your queries to account for extra fields/columns, instead you just specify the timestamps of interest as simple parameters to the query datasource. Also, Crux maintains a point-in-time (a.k.a timeslice) temporal index which is really a Z-Order Curve[0] that stores the two dimensions for fast lookups in a local KV store like RocksDB or LMDB. By contrast, a userland RDBMS implementation of bitemporality will be significantly slower to execute similar point-in-time "as-of" queries. [0] https://en.m.wikipedia.org/wiki/Z-order_curve https://en.m.wikipedia.org/wiki/Z-order_curve (I work on Crux)