Irmin is especially well-suited to applications that care about:
-
Content-addressability, either for its performance characteristics (i.e. heap sharing) or for its application semantics (i.e. “proof”-like objects and heap-exchange mechanisms). e.g. a distributed cache of build artefacts or a concensus mechanism.
-
Divergent eventually-consistent state, rather than the more strict consistency models offered by traditional DBs. e.g. a highly-decentralised application protocol or a fault-tolerant real-time web application.
-
Platform-agnosticism, in order to be able to deploy infrastructure on a wide range of hardware (including unikernels via MirageOS).
A good example of an application that fits all of the above criteria is Tezos.
In short: Irmin is suitable for applications that want a distributed, versioned heap and RDBs are suitable for applications that want a centralised store of schematic data with auto-derived indices and a transaction system.
These seem to me to be fairly mutually-exclusive goals, and so I don’t find the comparison to be particularly enlightening in and of itself; I would expect a choice of high-level DB architecture to be more or less forced by the requirements of the application. In your case, I would look into a document-oriented solution that meets your key requirements w.r.t. metadata, indexing and versioning. While it’s certainly possible to implement these in terms of Irmin, I don’t encourage it as a good use of your time 