> Part of the reason it hasn’t taken off is because of the additional complexity it imposes on programmers. My take is that it's specifically the additional co

> Part of the reason it hasn’t taken off is because of the additional complexity it imposes on programmers. My take is that it's specifically the additional complexity it imposes on _database_ programmers - the impacts across storage design, foreign keys and schema evolution when all data is bitemporal are profound. SQL:2011 introduced "temporal tables" but the design was arguably incomplete and implementing it ubiquitously requires a real re-think of database internals, so we're now over a decade on and these capabilities are still far from commonplace. > However, I think part of the reason it hasn’t become more popular, given the benefits it brings, is just the name. No disagreement from me there! Disclosure: I work on xtdb.com, building a new database engine where bitemporality is the default. I also spoke with Kent about this last week :)