Commanded, Meet EventSourcingDB - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

Commanded, Meet EventSourcingDB¶

Today we're delighted to celebrate a new arrival in the EventSourcingDB ecosystem: Thomas Gossmann has released a Commanded event store adapter for EventSourcingDB. Commanded is the de-facto framework for building CQRS and Event Sourcing applications in Elixir , and with this adapter it can now store its events in EventSourcingDB. If you work in Elixir and you've wanted to put EventSourcingDB underneath your aggregates and process managers, that option exists today.

What makes this exciting isn't a new line in a dependency file. It's what that line unlocks: an entire language community gains a first-class path to EventSourcingDB, without giving up the framework they already know and trust. Let's look at what the adapter does, how you'd put it to work, and why this kind of growth is exactly what we'd hoped to see.

Commanded, Now on EventSourcingDB¶

If you've spent any time in the Elixir world, you've almost certainly come across Commanded . It's the most established toolkit for CQRS and Event Sourcing on the BEAM, and it gives you the building blocks you'd expect: aggregates, commands, events, process managers, and projections, all wired together with the kind of explicitness Elixir developers tend to appreciate.

Teams reach for Commanded when they want the discipline of Event Sourcing without assembling all of the plumbing themselves. It handles command dispatch and routing, enforces consistency at the aggregate boundary, runs process managers that coordinate long-lived workflows, and keeps read-model projections up to date as new events arrive. It has been quietly powering production systems for years, and it carries the kind of battle-tested maturity that's hard to fake.

Commanded has always kept one thing deliberately pluggable, namely where the events actually live. Its own EventStore library keeps them in PostgreSQL , a general-purpose relational database pressed into the role rather than a store built for events; there's an in-memory adapter for tests; and through a long-standing dedicated adapter it can use Kurrent , which is a purpose-built event store. The event store is an interface, not a hard-coded dependency, and that's precisely what makes adding another option like this one possible.

The news, in one sentence: you can now point Commanded at EventSourcingDB. You keep your aggregates, your process managers, your projections, and the entire programming model you already know. What changes is the substrate underneath, the place where your events are appended, read back, and streamed to subscribers.

For an Elixir team that has committed to Event Sourcing, that's a meaningful new choice. You're no longer limited to the stores Commanded has supported until now; you can put your events in EventSourcingDB instead, and you can do it without rewriting your application.

What This Unlocks for Elixir Teams¶

Let's be precise about the appeal, because it isn't that Commanded can finally use a purpose-built event store. With Kurrent , it already could; its default EventStore, by contrast, leans on PostgreSQL, a general-purpose database rather than a dedicated one. What EventSourcingDB adds is a second purpose-built option with a distinctly different character. EventSourcingDB is purpose-built for events , append-only by nature and built around first-class streaming, and it reaches you over open standards rather than a bespoke protocol.

That last point is where it differs most from what came before. Your events are stored as CloudEvents and travel over plain HTTP, so they stay in an open, portable format and the integration surface stays small. Events are organized into hierarchical subjects rather than flat streams, which maps cleanly onto domain hierarchies and multi-tenant setups. None of this makes the existing choices wrong; it simply hands Commanded users one more dedicated store to reach for, and the freedom to pick the trade-offs that suit their project.

Getting started looks the way Elixir developers expect. You add the adapter to your dependencies and configure it alongside the rest of your application:

config :my_app, MyApp,<br>event_store: [<br>adapter: Commanded.EventStore.Adapters.EventSourcingDB,<br>client: [<br>api_token: "your-api-token",<br>base_url: "http://localhost:3000"<br>],<br>stream_prefix: "myapp",<br>source: "https://my.app"

Under the hood, the adapter builds on our official EventSourcingDB Elixir SDK , which we released earlier this year. That detail matters more than it might seem. The adapter didn't have to reinvent how to talk to the database; it could stand on a...