Want to try EventSourcingDB right now? Here's all you need:
docker run -it -p 3000:3000 \
thenativeweb/eventsourcingdb run \
--api-token=secret \
--data-directory-temporary \
--http-enabled \
--https-enabled=false \
--with-ui
Done! EventSourcingDB is running at http://localhost:3000.
Imagine you're standing at the counter of your local library. You want to borrow a book – let's say it's "2001: A Space Odyssey". You tell the librarian, they check if the book is available, stamp your card, and hand you the book. Simple, right?
EventSourcingDB 1.2.0 is available for download. Since we shipped 1.1.0, we've spent a lot of time listening – at conferences like KanDDDinsky, in customer calls, through GitHub issues, and in direct conversations with teams running EventSourcingDB in production. This release is our response to what you told us you needed most.
May 5th, 2025. After years of development, countless iterations, and exhaustive testing, we finally released EventSourcingDB 1.0. The CI/CD pipeline was green. All integration tests passed. The documentation was polished. We had tested the database on different ports, different operating systems, different deployment scenarios. Everything worked exactly as intended.
We allowed ourselves a moment of relief. A decade of learning, building, failing, and rebuilding had culminated in this release. The product was solid. We were ready.
Last week, my colleague Rendani and I found ourselves in Berlin's nhow hotel, surrounded by about 250-300 people who share our passion for Domain-Driven Design (DDD), Event Sourcing, and thoughtful software architecture. KanDDDinsky 2025 marked our first time attending this conference – not just as participants, but as sponsors and exhibitors for EventSourcingDB.
Golo: Frank, you are one of the managing directors at Digital Frontiers and also one of the architects and main developers of OpenCQRS. Over the past months we've seen a lot of interest in the framework, especially now with version 1.0 out. Some of our customers have even been building production systems with the release candidate for quite a while already, which shows how stable and usable it has been early on. Before we dive into details, let's start at the very beginning: can you tell us a bit about how OpenCQRS came to life? What triggered the idea and what gap were you trying to fill?
When we built EventSourcingDB, we didn't just create a storage engine for events. We wanted to give developers the right tools to work with those events in ways that are both practical and efficient. Very early on, we realized something important: while projections are great for predefined, recurring questions, they don't cover everything. Sometimes you need answers on the fly.
Today we're thrilled to celebrate an important milestone for the Event Sourcing community: the release of OpenCQRS 1.0. Built by our friends at Digital Frontiers, OpenCQRS brings first-class support for CQRS and Event Sourcing to the JVM world, with native integration for EventSourcingDB. This release matters deeply to us, not just because it adds another powerful tool to the ecosystem, but because it represents collaboration, shared vision, and the steady growth of something we have believed in for more than a decade.
Today we're pleased to announce the release of the official .NET Client SDK for EventSourcingDB, version 1.0. With this release, .NET developers gain first-class support for building event-sourced applications with EventSourcingDB – bringing the same level of quality and ergonomics we've already delivered for Go, JavaScript/TypeScript, PHP, Python, and Rust.
When we founded the native web back in 2012, our focus was straightforward: we wanted to share knowledge. At the time, JavaScript and Node.js were still newcomers in the enterprise world. We helped teams understand these technologies and make them productive. We ran workshops, taught trainings, and even wrote the first book in German language about Node.js. That period was about building a company – and building a community.