4 ms·

There seems to be a growth in the number of time traveling immutable-first databases available. We have OpenCrux, Datomic, TerminusDB, Noms, Dolt, and now Immud

by LukeEF 5y ago

There seems to be a growth in the number of time traveling immutable-first databases available. We have OpenCrux, Datomic, TerminusDB, Noms, Dolt, and now Immudb. Three using datalog for query and two forcing SQL (not sure about Noms). What sort of use cases are most common? GitHub repository says: > Companies use immudb to protect credit card transactions and to secure processes by storing digital certificates and checksums. But I am not sure how people are building that into their architecture to be honest.

clusterhacks 5y ago
I have used "immutable" schema designs when there were strong requirements for full audit needs over time. It works very well even in a normal RDBMs system. It also allows some very neat reporting e.g. compare the same report at different points in time. The basic idea was that every operation (create, update, delete) are actually normal SQL inserts and all reads are against views defined such that the most recent tuples are returned unless they are flagged as "deleted." I have typically used these types of designs in mostly simple applications with tables where the row counts are in the low millions of tuples. Dealing with this design in the billions of tuples (probably sharded somehow) might have motivated us out of normal RDBMs and into one of the specialized immutable DBs mentioned.
- ak39 5y ago
  Thanks. Can you comment on how this differs from a “mutable” RDBMS model but one with automatic history based on triggers for example?
  - akra 5y ago
    I would imagine there are a few differences. Events are the primary entity, and the current state is simply a projection of that not the other way around. Those events may come from other systems and are often defined in business terms, not SQL terms. For example an event may also constitute a business update which can update one or many tables. Think of a transaction event updating a balance for two accounts. TL;DR My thinking it allows you to capture more the intent of that event. Although I'm not sure you need an immutable database to do this from scratch - I've seen this in schema designs in the past?

by LukeEF 5y ago

clusterhacks 5y ago

I have used "immutable" schema designs when there were strong requirements for full audit needs over time. It works very well even in a normal RDBMs system. It also allows some very neat reporting e.g. compare the same report at different points in time. The basic idea was that every operation (create, update, delete) are actually normal SQL inserts and all reads are against views defined such that the most recent tuples are returned unless they are flagged as "deleted." I have typically used these types of designs in mostly simple applications with tables where the row counts are in the low millions of tuples. Dealing with this design in the billions of tuples (probably sharded somehow) might have motivated us out of normal RDBMs and into one of the specialized immutable DBs mentioned.

ak39 5y ago
Thanks. Can you comment on how this differs from a “mutable” RDBMS model but one with automatic history based on triggers for example?
- akra 5y ago
  I would imagine there are a few differences. Events are the primary entity, and the current state is simply a projection of that not the other way around. Those events may come from other systems and are often defined in business terms, not SQL terms. For example an event may also constitute a business update which can update one or many tables. Think of a transaction event updating a balance for two accounts. TL;DR My thinking it allows you to capture more the intent of that event. Although I'm not sure you need an immutable database to do this from scratch - I've seen this in schema designs in the past?