I think the main difference is that most/all Event Store type things don't do anything clever when it comes to efficient querying of past projections. Projections are usually focused on "now" and accessing the past means recalculating from scratch or periodic snapshots. At its core Crux pretty much is an event sourced architecture, but the events are internal and should not be complected with domain events and domain projections. I would simply model and store domain projections as new documents, rather than building more stateful in-memory projection layers. There are also good reasons to have on-the-fly or in-memory projections if the domain event logs are short and storage is a bigger constraint than latency. Event stores will have all the hooks for creating projections neatly preconfigured whereas there is some work to do that on top of the base Crux APIs. But conservely they don't offer anything as nice as Datalog for ad-hoc graph joins across projections. Hope that covers it...I'm not hugely experienced in the world of event stores though, I'll happily admit!

Oh also, to answer the bitemporal angle specifically, it gives you the ability to update the past projections (stored as documents) as the projection code changes. Some of these links may be of interest: https://news.ycombinator.com/item?id=19073370 https://andrewcmeier.com/bi-temporal-event-sourcing https://www.youtube.com/watch?v=xzekp1RuZbM

Awesome! Thank you. I’ll share this with the team.

Cool, no problem. In case it ever helps to know, I / the team is always happy to jump on a video chat and talk these things through in a group...we're all learning here 😄