Sierradb: a Distributed Event Store Built in Rust
Posted2 months agoActive2 months ago
tqwewe.comTechstory
excitedpositive
Debate
20/100
Event StoreDistributed DatabaseRust
Key topics
Event Store
Distributed Database
Rust
SierraDB is a new distributed event store built in Rust, sparking interest and discussion among HN users about its features, potential applications, and comparisons to other technologies.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
9h
Peak period
4
78-84h
Avg / period
2.2
Comment distribution13 data points
Loading chart...
Based on 13 loaded comments
Key moments
- 01Story posted
Oct 21, 2025 at 9:17 AM EDT
2 months ago
Step 01 - 02First comment
Oct 21, 2025 at 6:27 PM EDT
9h after posting
Step 02 - 03Peak activity
4 comments in 78-84h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 25, 2025 at 10:34 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45655393Type: storyLast synced: 11/20/2025, 12:47:39 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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...
But with increased resources, I can see some solutions being considered around snapshotting. For now the goal is heavily unix philosophy inspired: a really fast and purpose built event sourcing database
> 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 think a community, open source built project in Rust has been a missing piece I can hopefully help to solve.
I feel like I've been using XTDB as an event store?
https://docs.xtdb.com/intro/installation-via-docker.html
XTDB doesn't currently solve the problems of user-defined projections (via stored procedures, triggers, Incremental View Maintenance etc.) or multi-partition scaling.
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?
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.