[radarroark]

> Point 1 may be a problem if you're embedded.

Large dependencies are not only a problem in embedded programming. That sort of thinking is how we got to the explosion of dependencies and software complexity we're in today.

> Object databases have their place, but so do fully normalized database tables.

Agreed, but you can build a stricter data model on top of generic data structures. The idea is to keep them separate rather than hard-coding just one specific data model. See for example running DataScript on top of xitdb: https://gist.github.com/radarroark/663116fcd204f3f89a7e43f52...

> Tracking versions of rows is useful. I would argue that "reverting" is not, since the reverting would be better tracked by adding a new version as a forward update.

"Adding a new version" to revert is exactly what xitdb does. See this line, which appends a new "version" of the database whose value points to an older version:

    history.append(history.getSlot(historyIndex));

It's fine if you don't find immutability useful directly, but it is also what enables reading the db while writes are happening, which is clearly useful even if you don't care about time travel.