> Recently, a new type of question has entered the database arena: what did this data look like last Tuesday?

This question has been answerable in Dolt for years now.

Why are they storing a time period (start and end date) in the first example? Why not just store the date when the price comes into effect? That would make both overlaps and time travel impossible without using any constraints.

It can be super ugly to try and hand-manage date time range manipulation in a system with moving parts. It is, of course, possible, but it's a headache to try and pull it off when there is complex business logic focused on those datetimes and interactions between ranges. The period constraint is an excellent tool for trivially guaranteeing range coverage (in a case where, for instance, a customer is known to be active from a to b it helps ensure that there aren't any gaps created during the juggling of different sub-ranges) while the new DELETE FOR PERIOD OF syntax makes manipulating swathes of history (I don't care what was happening here this interval should now be X) much more trivial than before.

I remember reading about this feature for Oracle in the 2000s and was always interested to use it in a production environment.

It never came to pass when we used Oracle, maybe now with Postgres I will finally have a chance at it.