Fowler gets major props for quoting Doctor Who! 🙂

yeah - 'querying as appropriate' is fine when you've only got a couple of tables, but when you have explicit user-managed columns you then have to take them into account in every join of every query 🙂

more to manually performance optimise, too - to an RDBMS they're just ordinary columns - their inclusion in every join may be enough to cause it to choose an unsuitable plan; a bitemporal database knows more about them and so can optimise on your behalf

Crux, for example, indexes the content and the temporal information separately, so that a decent amount of the query can be executed on the content alone

So... "Performance"?

haha, yep 🙂 although day-to-day I think I'd value the ease and correctness higher, not having to worry that anyone querying the database has correctly applied the temporal filters every time - for the common 'as of now' case you pretty much transact and query Crux as if it's a regular atemporal database, but you still have the temporality support when you need it