[coxmichael]

This article[1] from 2015 has stuck with me for years, talking about the same approach. The interesting thing about transactional/bitemporal databases is really the effect on how we consume them with our applications. The schema can be separated from the transaction data, schema migrations become easy, tables become cached materialized views (with the cache updated concurrently at write time), reduced need for application-level cache, no cache cold start, and pub/sub becomes the norm.

[1] https://www.confluent.io/blog/turning-the-database-inside-ou...

(Nice to see it's still relevant – the article is linked at the very top of the crux about page: https://opencrux.com/about/what-is-crux.html)

[sixdimensional]

I’m the same regarding that article. I always thought of that article as a kind of “deconstruction” or “decoupling” and “rearrangement” of traditional DBMS architecture.

The end result you speak of is a more flexible data platform, which can handle more use cases, including applying decoupled parts to different things.

A good example, in my mind, is Apache Spark - which is like taking a compute and SQL query engine, making it distributed and decoupling it from the underlying storage. Now, suddenly SQL or code can be used on anything you can fit into a data frame, even streams - wow!

Pulling out the transaction log - and wow, suddenly we have durable, potentially immutable queues we can use for even long term storage.

I was so excited by the line of thinking in that article. :)