You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

DACI: How to implement a repository with history?



DriverChris Grote 
Due date

Tips and info



Contributors: I am seeking the right people to get involved in the decision. Add your comments to this page, let's get the conversation started.

Please add:

  • The people directly impacted by this so we can include them.
  • Any references to previous work and investigations that we can leverage.
  • Any constraints and challenges we need to consider to make this decision and following action plan.
  • Any additional options we should consider before making the decision.


A common scenario we come across with almost all metadata repositories we have seen is that they lack the ability to store historical information about metadata and respond to point-in-time inquiries. While Egeria's type system and APIs have been built from the beginning to support such history, we have not yet implemented a backend storage option that implements history.

Considering this comes up frequently as a common need, even to augment existing metadata repositories, providing such a historical store for metadata could be a somewhat narrow but nonetheless extremely common adoption point for Egeria.

Current state

We are currently considering implementation options for an initial approach to such a repository.

Data for decision support

  • Identification of potential technologies to use as the backing store for such a repository.

Options considered


Option 1: bi-temporal RDBMSOption 2: bi-temporal graphOption 3: ?


Using a bi-temporal relational database like DB2

Using a bi-temporal graph store like Crux

Rollout plan

Pros and cons


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

New approach

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.


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

Similar to existing

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

Embedded option

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

Pluggable backends

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



The resource requirements that might be necessary for a "true production" rollout are unclear, or the volume to which it can scale.

Estimated cost and effort





Original GitHub issue

Follow-up action items

  • No labels