Hacker News Reader

Comment by pphysch | Hacker News Reader

It's tempting to go "wow bitemporality is a jolly great idea! Let's make a bitemporal database where every field is bitemporal" but this elides the significant jump in complexity/overhead of such systems.

Bitemporality should be explicitly enabled on data where required, part of the database schema rather than default behavior. This could be a big chunk of your data, but unlikely to be 100%.

View on HN

I mostly agree, but it's the same as the argument for immutability in systems more generally: if you can afford the RAM / GC / storage costs then great. Eventually though costs will decrease and new systems will routinely capitalize on the productivity benefits in spite of reduced peak efficiency. HTAP database systems illustrate this trend.

But it's not clear to me that existing, popular database engines will ever be able to evolve to make bitemporality an efficient or easy default choice. And in the meantime countless person-years of effort are wasted rediscovering and solving the same time-related problems over and over.

A world where bitemporality was (somehow) a realistic default choice would be a simpler world, I reckon.

> A world where bitemporality was (somehow) a realistic default choice would be a simpler world, I reckon.

I think MongoDB sorta proves this theory false: "let's avoid RDBMS schema/migration hell by making everything a flexible JSON document".

As it turns out, JSON columns are a jolly good idea, but making that the dominant default i.e. MongoDB led to a bunch of other (perhaps unanticipated) issues. I believe it would be a similar situation with bitemporality.

So yeah, it would be cool if e.g. Postgres had fast native support for bitemporal fields in a way that makes them accessible without changing the whole paradigm.

I'm not convinced about that comparison. MongoDB entirely disregarded the relational model whereas bitemporality—as envisioned by Snodgrass et al. and standardised in SQL:2011—is merely an extension/evolution of it.

> it would be cool if e.g. Postgres had fast native support for bitemporal fields in a way that makes them accessible without changing the whole paradigm

100% agreed with you there. And there has been various work on patches & extensions in this area previously. Unfortunately I'm not sure Postgres' internals will ever be able to flex hard enough to deliver a decent "default choice" experience. At least not until some other system has proven the UX is really worth the effort (which I guess MongoDB did similarly achieve with native JSON handling).

As it turns out, other mature options offer this temporality out of the box. In Fauna (disclaimer: I work there) offers temporality out of the box so you can do a search on a record at a specific point in time in the past. It combines this with native JSON documents with flexible schema (so you can add additional notes as an audit trail) without disregarding relational modeling (it supports joins, foreign keys, normalization, etc.), and with low-latency distributed ACID writes nd transactions. A couple of other databases were mentioned here (Datomic and xtdb) that support this, and I believe it is just a matter of time where this will be more widely used. Two additional points to make: a) to the comment of "let's avoid RDBMS schema/migration hell by making everything a flexible JSON document" - that's a specific side effect of Mongo's design decision - since our db handles schema migrations quite elegantly, so I wouldn't be quick to assume that because Mongo did it that way that most systems will exhibit those side effects. b) The main reason I'm convinced this will be used a lot more (call it event-driven systems, temporal systems, etc) is because it will result in better-trained ML behavioral and prediction models too. So, might as well get ahead of this.

Reply on news.ycombinator.com