Xtdb: https://xtdb.com/
Terminus: https://github.com/terminusdb/terminusdb
Nessie: https://projectnessie.org/
Dvc : https://dvc.org
Liquid base: https://liquibase.org/
Datasette: https://datasette.io/
Still framing in my mind how schema evolution, x-temporal and e.g. scd in data modelling, version control etc. tie in together in an approach.
Good luck with your search.
https://www.dolthub.com/blog/2021-09-17-database-version-con...
If it’s a real product it’s cool, I’ve wanted something like this for a while (currently I just use git repos full of JSON files but this would be better I think).
If you want experiment quickly and aren't squeamish about putting your data on the internet, DoltHub is easier to get started with. DoltLab is just a (limited) self-hosted version of DoltHub.
- how are shas created?
- assuming you hash the entire diff, can columns be ignored? e.g. timestamps or other "unimportant" data
- do any two insertions into a table "conflict"?
- it's content addresses / merkle DAG all the way down. The commit's hash is something like meta (author, description, timestamp) + parents hash + root value hash. The root value is composed of the schema, and pointers to table and index maps. Tables and indexes are merkle DAGs of the table data organized in a structure a bit like a B-tree, but with cut points chosen by a rolling value hash in order to probabilistically re-synchronize on incremental changes. Some details: https://www.dolthub.com/blog/2020-04-01-how-dolt-stores-tabl... , https://www.dolthub.com/blog/2020-05-13-dolt-commit-graph-an...
- currently table data is stored row major for full rows of the table and so diffing cannot efficiently ignore individual columns.
- direct conflicts are computed on a row-by-row basis, using the primary key of the row. And then constraints and foreign key references are maintained and validated across merges and edits.
HTH, happy to answer any further questions :).
