4 ms·

Amazing. I always hated with passion keeping timestamps and messing the database design so I can have some sort of time awareness, I always thought that this i

by talles 10y ago

Amazing. I always hated with passion keeping timestamps and messing the database design so I can have some sort of time awareness, I always thought that this is supposed to be handled by the database itself, I'm just a user. I know there's Datomic[1] but its stack is way different than what people are used to (around here) and I'm yet to find an application that would justify using it (yeah, I'm not proud of that). If anyone from Cockroach happens to read this, I have some questions: * Are you guys the first database vendor to provide this as first class feature? * How is the time travel performance-wise? What if I have a product that rely on this heavily? * How the database would handle some deleted columns on the schema reappearing after some time? It would consider the same as before? What if the type is different? Kudos for the feature, I barely know CockroachDB but now I have a good reason to try it. [1]: http://www.datomic.com/ http://www.datomic.com/

mjibson 10y ago
Blog post OP here. No, we are not the first SQL vendor to provide this. And many other non-SQL databases also have this feature. Performance is faster than other reads, in general, because of less risk of transaction retries. Columns can come and go, and change types, and that is all handled correctly. If a column reappears as a different type, it will work correctly. This is because we also version the table schemas each time they change, so we can always fetch the correct schema when doing a time-travel query.