Skip to content

What's New

Welcome to the official EventSourcingDB blog – your source for announcements, articles, and insights. Here you'll find updates about product releases and improvements, feature announcements, background articles, and practical guidance for working with EventSourcingDB.

Whether you're exploring event sourcing, following the latest changes, or looking for deeper technical insights, this blog keeps you informed.

Kafka Is Not an Event Store

Every time a team sits down to build an event-sourced system, someone asks the same question: we already run Kafka, and Kafka is an append-only, ordered log, so isn't that exactly what Event Sourcing needs? The resemblance is real, and it is tempting. It is also superficial, and mistaking one for the other tends to get expensive months later, once the system is in production and the workarounds have quietly piled up.

So rather than arguing that Kafka is bad, because it is not, we want to do something more useful. We will first pin down what an event store actually has to do, then hold Kafka against that list and see where it stands. This is the first post in a small series that asks the same question of one candidate at a time. And for Kafka, the answer is the one that surprises people the least once they can see it laid out: it is an excellent tool, just not for this particular job.

We'll Take the Benefits, Hold the Rules

There's a moment that shows up in Event Sourcing projects again and again. The design is going well, the team is sold on the idea, and then a single hard requirement surfaces: GDPR's right to erasure. All at once, storing events immutably looks less like a feature and more like a liability. So the team grants itself one small exception – when someone asks to be deleted, they'll reach into the stored event and overwrite the offending field, turning an email address into "redacted". One small edit, applied rarely, to a system that is otherwise append-only.

It sounds harmless. It even sounds responsible. But that one exception quietly cancels a large part of the reason they chose Event Sourcing in the first place, and they likely won't notice until the day they need one of the guarantees that no longer holds. Because the benefits of Event Sourcing aren't a menu you order from. They all hang on a single thread, and that field overwrite cuts it.

ESDM Is Now Open Source

As of today, ESDM is available under the MIT license. The full source of the esdm toolchain, the schema that defines the language, and the documentation now live in a public repository on GitHub. You can read it, use it in any project, and build on it – at no cost and with no strings attached.

We introduced ESDM about two months ago, and we deliberately kept the source in our own hands at first, long enough to sharpen the language through a few rounds of real use before handing it to the world. That stretch is behind us. The core has settled, and today is the day we open it up.

Claude, Start My Database

When we released the Claude Code Plugin for EventSourcingDB at Easter, we proudly listed everything it did not need: no SDK, no MCP configuration, not even a Docker container. Claude had learned to speak EventSourcingDB fluently. But there was a quiet assumption baked into every conversation – that somewhere, someone had already started a database for Claude to talk to.

Version 1.1.0 of the plugin removes that assumption. Claude can now start a local EventSourcingDB on its own, and it has picked up a few habits that make longer sessions noticeably smoother: consistent event sources, uniform event type prefixes, and a deeper understanding of the CloudEvents format. In this post, we walk through what is new – along a session that begins with an empty terminal and ends with a queryable event store.

OpenCQRS 2.0: Tests That Read Like the Domain

In most software, testing is something you bolt on after the fact: you write the code, then you write tests to convince yourself the code does what you hoped. Event Sourcing quietly inverts that relationship. Because behavior is expressed as events, a test can read like a sentence about the domain: given these past events, when this command arrives, then these new events should follow. The test stops being scaffolding around the code and becomes the specification of what the system is supposed to do.

On June 26th, our friends at Digital Frontiers shipped OpenCQRS 2.0, and the change we keep coming back to leans all the way into that idea. The release modernizes plenty under the hood, but the part that matters most day to day is the redesigned testing support – a fluent DSL that makes those given/when/then specifications read less like test code and more like a conversation with the domain. Let's start with why that conversation is worth having at all.

Too Many Islands, Too Few Bridges: Notes from the Event Modeling Conference 2026

Every once in a while, you walk into a room and feel a particular kind of energy: the sense that a community is standing at the edge of something larger than itself. The first time I experienced this was in September 2011, in Brescia, at the first Node.js Conference Italy: around 250 people from across Europe, convinced they were looking at the next big thing in server-side software. I wrote an article about it back then, every bit as caught up in it as the people around me. As it turned out, we were right.

The second time was last week, in a converted industrial space in Munich, at the two-day Event Modeling Conference 2026, with around forty other people. The same restlessness, the same sense of momentum. And one question that kept resurfacing all day, in talks and in hallway conversations alike. By the end of the second day, that question had a name, scribbled across a flip chart and signed by nearly everyone in the room.

Don't Put That PDF in Your Event

Someone asked us recently what to do when an event has to carry a document. A signed contract as a PDF, a Word file, a scanned invoice. The same question comes up every few weeks, and over the years it has arrived in every shape imaginable: not just documents, but images, audio files, and more than once a video. The phrasing changes, the underlying worry does not. Something big needs to be remembered, and the event feels like the place to keep it.

The short answer fits in a single sentence: keep the big thing out of the event and put a reference to it inside. But the short answer is the least interesting part. The interesting part is why, because the reasoning leads straight back to a question most of us never stop to ask. What is an event, really, and what is it for?

Thinking in Events

Most of us never learned Event Sourcing as a way of thinking. We learned it as a collection of parts. An event store goes here. A read model goes there. When things turn asynchronous, you reach for a saga, and when reads and writes start pulling in different directions, you reach for CQRS. We assemble the pieces the way the tutorials drew them, and for a good while the system holds together.

Then a question arrives that no tutorial covered. Should this be one stream or two? Does this failure belong in the log? Who owns this piece of state? The patterns go quiet, because we learned their shapes without the reasons that gave rise to them. Underneath the patterns, though, there is something smaller and steadier, and a while ago we tried to write it down: a short manifesto that everything else turns out to be a consequence of. Here it is, and here is what it means.

Testing Without Mocks

Open the test suite of almost any business application and start counting the mocks. A mock for the repository, a mock for the clock, a mock for the email gateway, a mock for the payment provider. By the time the test finally reaches the code it was meant to check, half of the system has been replaced by stand-ins that you wrote yourself. The test runs, it turns green, and it tells you something. The question is what.

Here is the uncomfortable part: a test that passes because of its mocks can be worse than no test at all. No test leaves you knowingly uncertain. A green mock-driven test hands you confidence that nobody has any right to give you, because nothing guarantees that the mock still resembles the real thing. Mocks are not a testing strategy. They are a workaround for two problems: domain logic that is tangled up with infrastructure, and infrastructure that is too slow to touch in a test. Event Sourcing removes the first. A database that starts in milliseconds removes the second. This is what testing looks like once you stop pretending.