Genesis DB is a event sourcing database designed for applications that require immutable audit trails, temporal queries. It provides CloudEvents-compatible event storage with cryptographic integrity verification, a powerful query language, and built-in support for GDPR compliance.
Over the past months I've been working on Genesis DB an GDPR-ready event-sourcing database built for simplicity, performance, and real-world use.
One piece of feedback that kept coming up:
"Docker is great, but for local dev it can feel heavy, especially when I just want to spin up an event store and start building."
So I built Genesis DB LocalStack. A native macOS experience for event-sourced development:
What it does
- Runs Genesis DB locally, natively, no Docker daemon needed
- Launch instances in milliseconds
- Each project gets its own isolated DB + domain (*.genesisdb.local)
- Run multiple instances for microservices workflows
- Export/Import environments for fast team onboarding
- Config lives in plain text: version control friendly
Why?
Local dev today often means container orchestration before first code.
Genesis DB LocalStack tries to remove friction: install app > click > build.
Sometimes the fastest developer experience is still the simplest:
Real processes on your machine, predictable ports, zero orchestration overhead.
Is a native, Docker-free local event-store helpful to you?
Appreciate any feedback, especially from folks doing event sourcing and CQRS, perhaps even with Genesis DB, in production.
I've thought about that. Do you actually see a real use case for running a Mac as a server? Maybe if you're hosting an internal-only app and the Mac acts as the local database server.
Thank you for your comment! I think it's actually your very first one on Hacker News, or am I mistaken?
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.
It's a playful metaphor. We meant that the logs are thorough, reflective, and give you insights. They help you understand your system and its processes. No worries, you won't end up contemplating the meaning of life, unless you really want to. :-)
I figured. It was playful criticism. I don't think it lands. Most potential customers when looking at 10 competing products are IMO more likely to see that and go umm IDK what that means for sure and put your product in "maybe" list, which is really just the no list.
I understand. Honestly, it was never my intention to get rich with this project. Covering a bit of the development time, servers, and so on would already be nice. Since Genesis DB doesn't limit the number of instances you can run, I would have happily used it myself as a developer at that price point. I've thought about a one-time payment model before. But as I said, I do understand your perspective.
