Page History

Handles historical information natively at the storage layer, so should be simpler to implement point-in-time inquiry.

Takes a new approach to a backing store (relational) compared to our existing implementations (graph-based)

We are unaware of any open source, native bi-temporal RDBMS, so this would put a dependency on licensed commercial software.

Requires a fixed schema, which raises questions about how to both handle efficient queries (not storing things as unqueryable blobs) but also manage history when the type system itself (schema?) may have changed over the course of that history (ie. deprecated attributes and types)

Handles historical information natively at the storage layer, so should be simpler to implement point-in-time inquiry.

Close alignment with our current repository approaches that are more graph-focused than relational.

Provides a simple option to run in an embedded capacity, which could be useful for demonstration purposes (not requiring additional infrastructure and components).

Implemented using pluggable characteristics for its own backends, including both open source and commercial options.

It sounds like each document in Crux is essentially schema-less (tuples / triples-based), so it may be feasible to store multiple versions of a type across the history of a given instance of metadata 

The resource requirements that might be necessary for a "true production" rollout are unclear, or the volume to which it can scale. (We heard mention of "16 TB" (sounds plenty) but also "10 million triples" (with history, and one triple per attribute value, per instance, this sounds small?) – from subsequent conversations we confirmed that this is 10 billion triples rather than million, alleviating our immediate concerns.