Ten Years, One Goal

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.

But behind that practical consulting work, we were already carrying a bigger ambition. From the very beginning, we wanted to create software that put business logic at the center, not just technology. We had come across ideas like Command Query Responsibility Segregation (CQRS), Event Sourcing, and Domain-Driven Design (DDD) very early. At that time, these concepts were still niche: there were no books, no stable methodologies, no Event Storming yet. But the core promise – making business logic explicit and history auditable through events – instantly fascinated us.

That long-term vision led to our first real product experiment: wolkenkit. It was supposed to make Event Sourcing approachable and reduce technical complexity. On the way there, we learned an incredible amount – about architecture, about technology decisions, and also about the harsh realities of start-ups, Open Source and product development.

Early Contact with Event Sourcing¶

Our first encounter with Event Sourcing wasn't planned. A client had asked for help with their architecture and mentioned CQRS and Event Sourcing. We had no idea what those were and discovered quickly that there was almost no practical material. Event Storming hadn't been invented; Event Modeling and Domain Storytelling didn't exist. There were a few blog posts, but they were abstract and hard to apply.

We started to piece things together ourselves. The perspective shift was compelling: moving away from CRUD and tables toward events that capture business meaning and systems that can retell their own history. At the same time, it was difficult to enter this new mental model without guidance.

A turning point was a three-day workshop with Greg Young in London. We wanted to validate our self-taught understanding of CQRS and Event Sourcing. The good news: much of what we had built made sense. Even more important was the confidence that we were on a meaningful path. Later, a workshop with Alberto Brandolini on Event Storming added further depth. Those early years shaped us: we wanted to make these ideas easier to adopt.

The Vision Behind wolkenkit¶

That desire gave birth to wolkenkit, our first serious attempt to help developers build event-sourced systems without drowning in complexity. We set out to remove unnecessary technical jargon and make the API intuitive and business-focused. Commands, for example, shouldn't feel like heavy class hierarchies; they should be simple functions named after actions, such as acquireBook() instead of AcquireBookCommand. Aggregates – often an intimidating DDD term – we reframed as a natural trio of state, events, and commands.

Technically, we chose Node.js. JavaScript was the lingua franca of the web and seemed the easiest way to make entry simple. In 2017, we finally launched wolkenkit 1.0 during the enterJS keynote – a conference we had co-founded together with Heise and dpunkt. The initial response was positive: people liked the clarity and business-first approach.

Strengths and Limits Revealed¶

But success was mixed. We soon noticed clear limits. wolkenkit was too opinionated. We had made too many decisions for our users: Docker was mandatory and tightly integrated, Kubernetes wasn't considered at all. Applications worked well if you stayed on the narrow path we provided; step off it, and friction grew quickly. In hindsight, wolkenkit was more framework than library. We gave rails, but they became walls.

Technically, we also lacked maturity for a universal toolkit. Our event store relied on traditional relational databases – PostgreSQL, MariaDB, SQL Server. It worked, but never felt satisfying or natural. Supporting multiple databases added complexity without solving fundamental scaling and consistency issues.

The Hard Lesson of Open Source Sustainability¶

On top of technical lessons came business reality. We believed in Open Source and wanted to give back. So we released wolkenkit under a dual licensing model: free under AGPL for open projects, commercial license for proprietary ones. Fair, we thought – contribute back if you benefit commercially.

Reality looked different:

• Proprietary teams complained about paying and wished for MIT or Apache.
• Open Source users disliked AGPL as too restrictive and also wanted MIT or Apache.

In other words: our "fair trade" approach pleased no one. As soon as adoption required extra thought or cost, people moved on. That was sobering but valuable. Today there's a wide debate about how to fund Open Source sustainably; we lived that frustration a decade ago.

Combine licensing struggles with the technical rigidity, and it became clear: wolkenkit could not become the long-term foundation we envisioned. Yet we had gained something far more valuable: deep, lived experience about architecture, developer experience, business models, and product evolution.

Turning Point: Rethink and Refocus¶

The biggest insight was: be modular. Instead of prescribing an entire system, build an excellent core that others can assemble around. And that core, in event-sourced systems, is obvious: the event store. That's where truth lives – events are written, read, streamed, and replayed. Solve that problem well, and an ecosystem can grow naturally.

This realization closed a circle. When we first experimented back in 2012, we had naively tried to build our own database but weren't ready. Ten years later, with all those scars and insights, we felt prepared to do it properly.

From Lessons Learned to EventSourcingDB¶

When we decided to stop developing wolkenkit, we didn't want to stop building. We wanted to build better – with everything we had learned in mind.

Technology neutrality instead of monoculture: One of the first big changes: no single language lock-in. Our early bet on JavaScript had seemed pragmatic but left out many teams. In practice, large organizations have heterogeneous stacks: Go, Java, .NET, Python, and more. So we designed the core to be language-agnostic. A database accessed over a clean network API is the right abstraction – no runtime dependency, no forced stack.

Modularity instead of a rigid framework: We moved away from an all-or-nothing solution. Instead, we built a composable system: at the heart sits the event store, with lightweight SDKs and CLI tools that you can use or replace as needed. If someone wants a higher-level framework on top, fine – but it's no longer imposed.

Standards where helpful, freedom where necessary: Containerization changed the world since we first wrote wolkenkit. Docker is now default; Kubernetes is ubiquitous. But we resisted the urge to hardwire a single deployment model. EventSourcingDB runs well in containers and on Kubernetes, but you're free to integrate it however fits your environment. Our role is to empower, not constrain.

Enterprise-grade reliability and compliance: Another lesson came directly from client work: if you want to be taken seriously in production, you must bake in reliability and compliance from day one. That's why we invested early in things like cryptographic event signatures (Ed25519) for tamper-evidence, Dynamic Consistency Boundaries for controlled data integrity, and well-defined APIs for reads, writes, and subscriptions. We thought hard about auditability, schema evolution, and secure connectivity. None of this is marketing fluff; it comes from years of painful edge cases.

Developer experience first: Even while we opened up flexibility, we didn't want complexity to leak. So we built clear, predictable APIs, strong documentation, and SDKs in multiple languages. We want developers to focus on modeling their domain, not fighting infrastructure.

Making Experience Visible¶

By the time EventSourcingDB took shape, we had spent a decade exploring, failing, and refining. That journey shows up everywhere in the product:

• We've lived the trap of "framework too strict" and now aim for guidance without lock-in.
• We've seen where relational databases fall short as event stores and addressed those constraints natively.
• We've been burned by underspecified APIs and now design them deliberately and version them carefully.
• We've felt the pain of scaling, operations, and compliance; today those are part of the foundation.

This isn't theory from books – it's scars turned into patterns.

Community and Thought Leadership¶

Sharing what we learn has always been part of who we are. Over the years we've spoken at conferences – from enterJS, which we co-founded, to Developer Week (DWX), Basta!, Software Architecture Gathering, and countless meetups. We've written in magazines like Heise Developer, iX, and dotnetpro. We've published books. Our YouTube channel now reaches tens of thousands of developers.

Those platforms weren't marketing tactics at first; they were simply how we processed and shared what we were discovering. But they became something bigger: a network of practitioners and peers who challenge, question, and push us to do better. That community shaped the decisions behind EventSourcingDB as much as any internal discussion.

We also invested in our own learning: workshops with pioneers like Greg Young and Alberto Brandolini helped us validate and deepen our understanding. And we didn't just talk about ideas; we built internal tools and applications to stress-test them long before shipping anything.

Today and What Comes Next¶

EventSourcingDB today is the direct result of that decade-long arc. It's not an overnight hack or a weekend side project. It's the distillation of years of architecture work, product iteration, and hands-on experience with event-sourced systems in real companies – and that depth of real-world experience is what sets it apart from the wave of recent newcomers, who often start from a clean slate but without the scars of a decade of building and running event-sourced systems.

We've learned that an event store must be more than an append-only log. It must guarantee integrity and safety, scale reliably, and fit into diverse infrastructures – from on-premises to containers to cloud. It must be auditable and help teams meet compliance without sacrificing developer experience.

That's why EventSourcingDB was built with enterprise readiness from the ground up: tamper-evident events, controlled consistency, strong APIs, evolvable schemas, reliable crash-recovery, and flexible deployment. And yet it remains approachable – so developers can stay focused on modeling the domain.

At the same time, we keep our process transparent. Roadmaps, features, and design reasoning are visible; we know trust in infrastructure software grows slowly and must be earned.

Our own journey isn't finished either. We continue to push for better developer experience, better tooling around projections and analytics, and stronger security and compliance integrations – because those needs evolve constantly. We're not doing this by adding features for the sake of having more, but by putting robustness, reliability, and quality first.

Looking back, it's striking how much has changed: when we started, there were barely any resources, no Event Storming, no vibrant Event Sourcing community. Today, the field is alive and growing, and we've played a part in that. But perhaps the most important takeaway isn't about any single technology. It's this:

Real expertise comes from iteration. You build, you fail, you learn, and you refine – sometimes over a decade.

For us, EventSourcingDB is the embodiment of that learning process. It's the software we wish we'd had ten years ago. And while it's built for event-driven systems, the deeper story is universal: focus on what's essential, learn from what breaks, and keep evolving until the core is right. And if you like this approach, get started with the Getting Started guide.