Data history is not a problem, you can simple implement all the time travel things in existing Postgres by just adding two columns and use soft delete. This talk does not address this problem at all. How do you deal with column changes over time?
> you can simply implement all the time travel things in existing Postgres by just adding two columns and use soft delete The problem is that you have to be an expert and spend a lot of energy to do this correctly (and maintain it!), which is a huge risk, and then also your app ends up more complex (harder to evolve) and likely much slower than strictly necessary because the behaviours are essentially opaque to the DBMS. Postgres also gets quite expensive if you have a lot of history and access it rarely. > How do you deal with column changes over time? XTDB accretes new columns without having to do any expensive operations because it is columnar. The schema can only grow. If you insert a new type into an existing column then the schema shows a widened union type.
Data history is not a problem, you can simple implement all the time travel things in existing Postgres by just adding two columns and use soft delete. This talk does not address this problem at all. How do you deal with column changes over time?
> you can simply implement all the time travel things in existing Postgres by just adding two columns and use soft delete
The problem is that you have to be an expert and spend a lot of energy to do this correctly (and maintain it!), which is a huge risk, and then also your app ends up more complex (harder to evolve) and likely much slower than strictly necessary because the behaviours are essentially opaque to the DBMS. Postgres also gets quite expensive if you have a lot of history and access it rarely.
> How do you deal with column changes over time?
XTDB accretes new columns without having to do any expensive operations because it is columnar. The schema can only grow. If you insert a new type into an existing column then the schema shows a widened union type.