Fork me on GitHub
Jack Park19:10:49

naive question: is there a reason to persist Datalog in a graph database vs a KV store?


Hi Jack 🙂 this answer is assuming that you are referring to persisting Datalog facts, rather than Datalog queries. I'd say the difference between a "graph database" and a KV store here is one of abstraction. Graph databases offer a high-level API but may use many different strategies for persistence and indexing behind the scenes, for instance uses sparse matrices and uses succinct data structures. However a sorted-KV interface (whether backed by a b-tree, LSM or something more fancy) is also a valid and useful storage abstraction on which to build a graph database - this is essentially the approach taken by all of the Datalog engines listed on (with the exception of Asami, IIRC).


All layering of abstractions come with costs and all underlying data structures have different performance & scaling trade-offs. For instance sparse matrices are expensive to update, which makes them broadly inappropriate for OLTP use-cases (as I understand it), but they are a good order of magnitude faster for querying than anything else.

Jack Park16:10:22

Very helpful. Thanks 🙂

🙏 1