[HN Gopher] SierraDB: A distributed event store built in Rust
___________________________________________________________________
SierraDB: A distributed event store built in Rust
Author : tqwewe
Score : 56 points
Date : 2025-10-21 13:17 UTC (3 days ago)
(HTM) web link (tqwewe.com)
(TXT) w3m dump (tqwewe.com)
| jayy-lmao wrote:
| This looks really cool!
|
| 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.
| jauntywundrkind wrote:
| In memory partitions, yeah?
|
| 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...
| curtistyr wrote:
| Interesting point about SlateDB - I've been thinking about how
| different architectures handle event sourcing and stream
| processing. SierraDB's append-only model with fixed partitions
| is really compelling for event sourcing, but I'm curious how it
| compares to something like SlateDB when you need more general-
| purpose streaming capabilities. Do you think the trade-offs
| between these approaches are starting to converge, or are they
| solving fundamentally different problems? Also, SierraDB's use
| of RESP3 is smart - anything that reduces client complexity is
| a win in my book.
| conceptme wrote:
| Does it also have snapshot capabilities, as mostly over time it
| becomes very difficult to replay events due to the shear amount
| of them.
| 12_throw_away wrote:
| Very excited to see how this progresses! Honestly, it's always a
| little surprising to me that event store architectures aren't
| more widely used. The article is extremely correct about why:
|
| > 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 nee 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(tm) world.
| _mocha wrote:
| I've wanted to do this for the last 7 years and never got around
| to it. Couldn't be more proud that you put in the grit to bring
| this to fruition!
| Havoc wrote:
| Was a bit surprised to see this end in a docker instruction
| rather than k8s given the emphasis on multi node, replication
| etc.
| rufusthedogwoof wrote:
| Hi.
|
| I feel like I've been using XTDB as an event store?
|
| https://docs.xtdb.com/intro/installation-via-docker.html
| refset wrote:
| SierraDB looks closer to Rama than XTDB
| https://blog.redplanetlabs.com/2024/01/09/everything-wrong-w...
|
| XTDB doesn't currently solve the problems of user-defined
| projections (via stored procedures, triggers, Incremental View
| Maintenance etc.) or multi-partition scaling.
___________________________________________________________________
(page generated 2025-10-24 23:01 UTC)