| ▲ | I Built an Event-Sourcing Database Engine: Meet Genesis DB(genesisdb.io) |
| 45 points by patriceckhart 6 days ago | 40 comments |
| |
|
| ▲ | Rickasaurus 3 days ago | parent | next [-] |
| Seems like very cool tech. 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. |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | 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. |
|
|
| ▲ | starrax 12 hours ago | parent | prev | next [-] |
| I find GenesisDB difficult in several respects. On the one hand, there is its similarity to EventSourceDB and the fact that it is almost a 1:1 copy, for example in terms of the query language. On the other hand, the performance of GenesisDB is anything but acceptable, i noticed some query language bugs and the PHP and JavaScript SDKs are offered without testing. But now comes the critical point: it's a one-man show, without open source, which raises the question: why should as a person or as a company rely on GenesisDB for its project? |
| |
| ▲ | patriceckhart 3 hours ago | parent [-] | | 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. |
|
|
| ▲ | patriceckhart 6 days ago | parent | prev | next [-] |
| Hey! 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! |
| |
| ▲ | NomDePlum 3 days ago | parent | next [-] | | Amazing, well done. Having used Go for something similar can understand why you chose that for this venture. Wondering if there was anything in particular worked out for you with that decision? | | |
| ▲ | patriceckhart 2 days ago | parent | next [-] | | I've been using Go for some time now. I've never programmed with Rust before, and it seemed appropriate to use Go for this project. In my initial prototypes of an event sourcing system that I experimented with last year, I used PHP (yes PHP) with either PostgreSQL or MySQL and a few other things. A major advantage of Go is its backward compatibility, which certainly makes maintenance easier. | |
| ▲ | goloroden 3 days ago | parent | prev [-] | | Just a little hint: Read the other comments as well… |
| |
| ▲ | capestart 6 days ago | parent | prev [-] | | Congrats on hitting 1.0. love the focus on simplicity and real world dev workflows | | |
| ▲ | patriceckhart 6 days ago | parent | next [-] | | Thanks a lot! That means a lot. Simplicity + real-world workflows is exactly what I wanted to nail. | |
| ▲ | goloroden 3 days ago | parent | prev [-] | | Just a little hint: Read the other comments as well… |
|
|
|
| ▲ | unconed 2 days ago | parent | prev | next [-] |
| Event sourcing gives you all the technical overhead of replayable transactions while giving your end-users none of the benefits (e.g. undo/redo). It's purely an infrastructure-level feature that only makes auditors and sysadmins happier. |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | Event sourcing doesn't directly address this. However, the "undo" functionality is not a feature of event sourcing itself, but rather something your application needs to implement. Sure, you can implement that functionality without event sourcing, but it becomes problematic if you decide to add it later. |
|
|
| ▲ | citizenpaul a day ago | parent | prev | next [-] |
| What does "Logs like a Philosopher." Mean? Did you mean sage? I dont want my logs to make me contemplate the meaning of life. |
| |
| ▲ | patriceckhart a day ago | parent [-] | | 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. :-) | | |
| ▲ | citizenpaul 16 hours ago | parent [-] | | 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. | | |
| ▲ | patriceckhart 3 hours ago | parent [-] | | I appreciate your remarks and the perspective, that's valuable feedback. I'll think about adjusting it to make the message clearer. |
|
|
|
|
| ▲ | AndrewKemendo 2 days ago | parent | prev | next [-] |
| One of the big issues I’ve always found with all streaming services is rehydration post migration or for HA or failover. Has this group done testing for how long it takes for different sizes of streams to rehydrate? |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | One approach is to keep track of the ID of the last consumed event and use that as the starting point for rehydration. That way, even after a migration or failover, the stream can resume efficiently without replaying the entire history. |
|
|
| ▲ | goloroden 3 days ago | parent | prev | next [-] |
| Hi there, 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 |
| |
| ▲ | koakuma-chan 3 days ago | parent | next [-] | | See what? What legal investigations? I don't get what you are trying to say. | |
| ▲ | 15155 3 days ago | parent | prev [-] | | Absent substance, how is this not just self-promotion? |
|
|
| ▲ | inthebeginning 3 days ago | parent | prev | next [-] |
| tbh – this pretty much looks like they straight-up copied another database that dropped earlier this year. looks like GenesisDB grabbed all its ideas from here: https://hub.docker.com/r/thenativeweb/eventsourcingdb take a look and see for yourself… #copycat |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | I've definitely taken inspiration from some great ideas out there, but Genesis DB is built on my own design choices and implementation. The earlier concepts behaved quite similarly, with the main difference being that back then I hadn't implemented the CloudEvents standard or event hash-chaining yet. I later found both to be really valuable additions. The idea of event chaining isn't new for example, I just hadn't had it on my radar for very long. |
|
|
| ▲ | jdc0589 3 days ago | parent | prev | next [-] |
| this looks very cool. Rigging together your own event sourced Db is doable, but it gets a little annoying over time to keep DIYing everything, doing snapshot optimizations, etc... one note: searchability on your query language named GQL may not be great, given the whole graphql thing. |
| |
|
| ▲ | cpursley 3 days ago | parent | prev | next [-] |
| Why not just hook up postgres to something like https://github.com/cpursley/walex or any of the other libraries like Debezium, https://sequinstream.com? Isn't postgres enough? |
| |
| ▲ | Nelkins 2 days ago | parent | next [-] | | There's also https://github.com/message-db/message-db Admittedly, these options seem to not be quite as user friendly as OP's solution. | |
| ▲ | patriceckhart 2 days ago | parent | prev | next [-] | | I've experimented quite a bit and I'm familiar with some of those concepts, in fact, I even looked at them early on in development. But my goal was to build more than just a wrapper around SQL. | |
| ▲ | koakuma-chan 3 days ago | parent | prev | next [-] | | I know right? This whole CQRS+ES thing feels like a scam. | |
| ▲ | AndrewKemendo 2 days ago | parent | prev [-] | | +1 for debezium but that’s post deployment cdc as a stream API We need more native streaming databases overall |
|
|
| ▲ | mandeepj 3 days ago | parent | prev | next [-] |
| Congratulations! I don’t think the db engine is open source. Any plans to do that? |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | Not at the moment, but I'm considering a one-time payment option since people generally dislike subscriptions. |
|
|
| ▲ | dev_l1x_be 3 days ago | parent | prev | next [-] |
| Where can I see the architecture and the libraries used for this project? |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | That's a valid question. At the very least, disclosing the libraries being used might even be mandatory. I'll check on that asap and add it to the documentation. |
|
|
| ▲ | ImPleadThe5th 3 days ago | parent | prev | next [-] |
| Nobody tell Greg Young! |
|
| ▲ | vivzkestrel 2 days ago | parent | prev | next [-] |
| how does it differ from timescale db? |
| |
| ▲ | patriceckhart 2 days ago | parent [-] | | TimescaleDB looks great and is built on top of Postgres. Genesis DB, in contrast, is a straightforward (if not simpler) event store that manages data differently than Postgres. That said, TimescaleDB is definitely worth a look. |
|
|
| ▲ | spoudaia 3 days ago | parent | prev | next [-] |
| Really? You built this bc “tools felt too heavy, opinionated, or expensive” — LOL… or just bc there was such a nice blueprint you could use for inspiration…?! Here is the original: https://www.eventsourcingdb.io |
|
| ▲ | Snapstromegon 3 days ago | parent | prev [-] |
| [dead] |
