[detaro]

What makes crux's internals less complicated than a more conventional database?

[refset]

1) the single-writer principle of the transaction log means there's no need for any transactional locking

2) the separation of reads and writes allows for elegant horizontal read-scaling without coordination/consensus

3) pluggable storage backends implemented as simple Clojure protocols (as the sibling comment mentions), which eliminates a large number of performance and durability concerns

4) combining schema-on-read with entity-attribute-value indexing means there's no need to interpret and support a user-defined schema

5) Datalog is simpler to implement and use than the full SQL standard or alternative graph query languages

...I work on Crux :)

[simplify]

Please tell us more about point 5!

[refset]

Crux uses a Worst-Case Optimal Join [0] algorithm with bitemporal indexes, and the Datalog-specific query layer is implemented in less than a thousand lines of Clojure: https://github.com/juxt/crux/blob/master/crux-core/src/crux/...

SQL certainly provides a lot of bells and whistles but Crux has the advantage of consistent in-process queries (i.e. the "database as a value") which means you can combine custom code with multiple queries efficiently to achieve a much larger range of possibilities, such as graph algorithms like Bidirectional BFS [1].

[0] https://arxiv.org/pdf/1803.09930.pdf

[1] https://github.com/juxt/crux/blob/master/docs/example/imdb/s...

[tincholio]

I suspect the gp was referring to it using either Kafka or RocksDB for storage.