you can work with it as easily as with the current data. I have at least not seen that in any other database.
At the cost that working with your current data is as hard as working with the historical data. This does not come for free, and the only way to have such a versioned history is at a significant cost to generalized query performance -- sure certain things (like a single scalar lookup) can be fast, but generalized queries will be terrible. I'm sure there will be some map/reduce claimed solution.
For me at least Datomic is the new standard and only if I have a special use case I would go to something else.
This is an incredible and rather ridiculous statement.
"The only way to have such a versioned history is ..." is incorrect, and trivially so.
Datomic provides one existence proof of this: Datomic's history data is kept in distinct data structures, so it is "pay as you go" -- querying history is more expensive, because there is more stuff. Querying the present is cheaper.
Datomic queries are datalog, and do not require writing map/reduce jobs.
At the cost that working with your current data is as hard as working with the historical data. This does not come for free, and the only way to have such a versioned history is at a significant cost to generalized query performance -- sure certain things (like a single scalar lookup) can be fast, but generalized queries will be terrible. I'm sure there will be some map/reduce claimed solution.
For me at least Datomic is the new standard and only if I have a special use case I would go to something else.
This is an incredible and rather ridiculous statement.