Have always wanted to dip my toe in EventStoreDB/Kurrent but this looks super intuitive and nice to use. Especially like the js projections, can imagine it being really handy in prototyping or ad-hoc reporting.

It's persisted to S3 storage, but SlateDB feels like it might sort of have some fit, maybe, as a scale-out distributed LSM-tree. https://slatedb.io https://news.ycombinator.com/item?id=41714858

There's an old 404 post too that looks like a reasonably on target introduction: Why SlateDB is the right choice for Stream Processing. https://web.archive.org/web/20241102212325/https://www.respo...

> there's absolutely no clear cut way of approaching it for new projects

That's definitely my experience - there's no open source "batteries-included" event store where you can just `docker compose up` and start sourcing your events right away. (Maybe KurrentDB née EventStoreDB might offer something like this? But unfortunately, it has a weird license and feels heavily pivoted towards SaaS). And if you want to implement it yourself, a lot of the writing about event stores comes from the the Enterprise Design Patterns™ world.

I feel like I've been using XTDB as an event store?

https://docs.xtdb.com/intro/installation-via-docker.html

Would we say this is divergent? Cassandra, DynamoDB, and many others allow you to specify the consistency of reads at the request level.

> Here's where SierraDB diverges from traditional distributed databases: reads don't require quorum. Instead, each event stores a confirmation count in its metadata. When a write achieves quorum, a background process broadcasts this confirmation to all replicas, updating their local confirmation counts. This means any single node can serve consistent reads without network round-trips - a massive performance win.

I have no context outside of this blog post, but this seems actually divergent from the typical definition of consistency given its not linearizable. What systems benefit most from this low latency stale-but-ordered consistency guarantee?