Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
crux
Discontinued General purpose bitemporal database for SQL, Datalog & graph queries. Backed by @juxt [Moved to: https://github.com/xtdb/xtdb]
-
I haven't used `temporal_tables` but I have built similar temporal systems on Postgres in the past. (Judging by https://github.com/arkhipov/temporal_tables#usage at least.)
The trouble with these sorts of approaches is that they solve temporality the same way we did in the 90s: Add an `entity_history` table, timestamp your tx-time and valid-time, and add a trigger to version your entities. This must be done for each entity you want to version across your temporal plane.
It would appear that `temporal_tables` doesn't support bitemporality yet. It only has tx-time (system time). But even if it did, this approach doesn't help you with live data. Because the `entity` table corresponding to the `entity_history` table still permits destructive updates, temporal queries are always in the realm of audits and can't answer questions about the application data directly. Add to that a completely manual system of querying the temporal information, and the resulting systems tend to get quite hairy, which is why Martin recommends avoiding bitemporality whenever you can. Unfortunately, that recommendation (while sound, for relational databases) means that bitemporality is expensive and manual if and when it's implemented.
A bitemporal database like Crux encodes the temporal plane into all the data stored in it, making it transparent to the user. There's no up-front setup cost to bitemporality and a query's default time on both time axes is "now", allowing the user to ignore temporality entirely except in those few instances where it is required -- but when it is required, it is global.
Sure, I can appreciate that native support for a feature like this is nice.
As I understand it, most implementations (including another one for bitemporality[1]) involve either audit tables, as you mention, and/or additional support columns. It's as if the "now" representation is simply a narrow lens onto the underlying data.
That said, PostgreSQL encodes and has battle-tested decades of database functionality including an ecosystem around those, so I'd be a little wary of switching technology even if it does solve one individual problem thoroughly. Everything has to start somewhere, though.
[1] - https://github.com/scalegenius/pg_bitemporal
Not the OP, but Reladomo is a Java ORM which supports bitemporal history.
https://github.com/goldmansachs/reladomo