I Built an Event-Sourcing Database Engine: Meet Genesis Db
Posted4 months agoActive4 months ago
genesisdb.ioTechstory
heatedmixed
Debate
80/100
Event SourcingDatabaseOpen Source
Key topics
Event Sourcing
Database
Open Source
The creator of Genesis DB, a new event-sourcing database engine, announces its production readiness, sparking a discussion about its originality, performance, and potential adoption.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
N/A
Peak period
20
Day 4
Avg / period
6.7
Comment distribution40 data points
Loading chart...
Based on 40 loaded comments
Key moments
- 01Story posted
Sep 15, 2025 at 4:25 AM EDT
4 months ago
Step 01 - 02First comment
Sep 15, 2025 at 4:25 AM EDT
0s after posting
Step 02 - 03Peak activity
20 comments in Day 4
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 25, 2025 at 4:43 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45247381Type: storyLast synced: 11/20/2025, 12:32:34 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.
I'm Patric, and I just hit a major milestone - Genesis DB 1.0.(1) is officially production-ready.
Why I built this: Existing event sourcing tools felt too heavy, opinionated, or expensive. I wanted something that matches how developers actually think about events - simple, transparent, and powerful.
What Genesis DB is:
- Event sourcing database engine written in Go
- HTTP + JSON interface (no proprietary protocols)
- CloudEvents native with zero vendor lock-in
- One-command backups/restores
- Built-in Prometheus metrics & structured logging
Major features that made it to 1.0:
- Smart validation - Preconditions act as gatekeepers, enforcing business logic before writes hit the database
- Schema registration - Automatic event validation for type safety and data consistency
- Native GDPR compliance - One-command user data deletion, full data portability, built-in audit trails
- Battle-tested performance - Thousands of events/second, zero data loss, stable under load
- ...
The journey:
- Started because I love event-driven architectures but hated the tooling complexity
- A few versions, each adding features
- Now processing real production workloads across multiple industries
Want to try it? - Free tier: 10,000 events for testing/small projects (I’m not here to be the biggest cost factor in any business. If you’ve got special requirements, let’s talk.)
- Self-host or use the managed platform (coming soon)
Full docs at https://docs.genesisdb.io
Thanks for reading!
I think the adoption hurdle will be hard unless you have a free plan that can be used for small things indefinitely. Having a hard cap on events would make me pass on this for fun side projects, which is where I would pivot later from to work projects. Just throwing that out there. This is why my last work project was supabase, I was using their free tier for some fun personal stuff.
If you have another vector for adoption that's fine too.
one note: searchability on your query language named GQL may not be great, given the whole graphql thing.
What a coincidence… ;-)
Admittedly, these options seem to not be quite as user friendly as OP's solution.
We need more native streaming databases overall
https://hub.docker.com/r/thenativeweb/eventsourcingdb
take a look and see for yourself… #copycat
I’m one of the creators of EventSourcingDB, and the CTO of the native web (the company behind EventSourcingDB).
Because of ongoing legal investigations I can’t comment any further, but I’d like to provide you with some links, so you can see for yourself:
https://www.eventsourcingdb.io
https://docs.eventsourcingdb.io
https://hub.docker.com/r/thenativeweb/eventsourcingdb
https://www.cqrs.com
https://www.eventsourcing.ai
Has this group done testing for how long it takes for different sizes of streams to rehydrate?
"Logs like a Philosopher."
Mean? Did you mean sage? I dont want my logs to make me contemplate the meaning of life.
If you run into bugs and want to share them, please just open an issue in the GitRepo's, or send us a message, ... Genesis DB is already being used in production projects, and so far issues that came up have been addressed in newer builds, including performance.
On performance specifically, it would be really helpful to know more about your setup: machine, architecture, how much RAM, ... Performance issues mainly existed in the very early versions, some of which were still SQL wrappers.
On the "one-man show" point: The architecture of your software can allow you to swap out the underlying database system, meaning you're not dependent on anyone. Thanks to CloudEvents, your data remains compatible with other CloudEvents-supporting systems.
In the end, it's up to everyone to decide which software they want to use.
Here is the original:
https://www.eventsourcingdb.io