You can use it for "what if" analysis. - Take a fork of the database - Transform data in the fork. i.e. costs+5% - Point your current queries to run on the fork

You can see how with just the effort repointing queries a reporting app could show the real world and the world you are modelling.

That’s helpful, maybe I’m naive but isn’t that like an Excel workload? I haven’t seen scenarios where the entire database needs that kind of functionality. Can you elaborate on what kind of data and business problem one would be working on where they need that level of robust versioning?

Uses cases for a versioned in branches data store that are not blockchain related.

0) The most obvious use case is to replace git, because git proper doesn't handle big files very well, let alone bigger than RAM structured data. Mind the fact you might still need an ad-hoc solution for binary data. WT does have a limitation on value size.

1) There is various data science uses cases, like sharing data [0] or A/B testing stuff.

2) Anywhere you need an audit trail .ie you need to look back at previous states, whether it is for debugging purpose or domain logic

versioned datastore is a compromise between event sourcing (pure log) and non-versioned databases.

[0] Collaborative Open Data versioning: A Pragmatic Approach Using Linked Data

[1] https://en.wikipedia.org/wiki/Audit_trail

edit: cosmit.

A real-life situation I ran into:

3) Take a copy of the data store offline, and later merge it back into the online database

Manually resolving conflicts is fine. The alternative is to rebuild a system on Couchbase/pouchdb, or rewrite on event sourcing, neither of which - when the system otherwise lends itself to RDBMS - is my choice.

Does the OP support merging? I didn’t see that.

No it doesn't, which seems to eliminate a lot of use cases. Merging is listed in the nice-to-have-in-the-future section.

Data modeling under the many worlds interpretation.