Today we're excited to announce the release of the official Elixir Client SDK for EventSourcingDB, version 1.0. If you're building event-sourced systems on the BEAM, you now have first-class support for writing, reading, and observing events from your Elixir applications.
Elixir has earned its place as one of the most compelling platforms for building fault-tolerant, distributed systems. With this SDK, we're bringing EventSourcingDB into that world, and we've made sure it feels like Elixir from the ground up.
Why Elixir Matters¶
The BEAM virtual machine, originally built for Erlang, has a reputation that precedes it. It powers some of the most demanding real-time systems in the world, from telecom infrastructure to financial trading platforms. Elixir builds on that foundation with a modern language that makes the BEAM's superpowers accessible to a much wider audience.
What makes the BEAM special is its approach to concurrency and fault tolerance. Lightweight processes, message passing, supervision trees, and the "let it crash" philosophy create systems that stay up when things go wrong. These aren't theoretical benefits. Companies in fintech, IoT, healthcare, and telecommunications rely on them every day.
The Elixir ecosystem has grown rapidly around frameworks like Phoenix for web applications, LiveView for real-time user interfaces, and Nerves for embedded systems. What these all share is a focus on responsiveness, reliability, and real-time communication. That's exactly the kind of environment where Event Sourcing thrives.
There's a natural affinity between Event Sourcing and the BEAM's architecture. In an event-sourced system, everything that happens is captured as an immutable event. In the BEAM, everything communicates through messages. Both paradigms share the idea that state is derived, not stored directly, and that the history of what happened matters more than a snapshot of where you are right now. If you've been thinking about Event Sourcing from an Elixir perspective, you've probably already noticed how well the two fit together. We wrote about this idea of capturing what happens rather than overwriting state in an earlier post, and it applies particularly well to the BEAM's process model.
Built for the BEAM¶
We didn't want this SDK to feel like a port from another language. We wanted it to feel like something an experienced Elixir developer would write. That meant embracing the idioms, conventions, and patterns that make Elixir code a pleasure to work with.
Every operation that can fail returns the familiar {:ok, result} or {:error, reason} tuples. If you prefer to work with exceptions, every function also has a bang variant that raises on error. You choose the style that fits your code.
Reading and observing events return lazy streams. That means you can process millions of events without loading them all into memory at once. You can pipe them through Enum or Stream functions, filter, map, and reduce, exactly the way you'd work with any other enumerable in Elixir. This is particularly valuable for building read models and projections where you process large event histories into queryable views.
Pattern matching works naturally with all SDK types. Preconditions, events, and errors are all structs, so you can match on them in function heads, case expressions, or anywhere else you'd expect. The SDK uses TypedStruct for all its data types, giving you compile-time type safety and excellent integration with tools like Dialyzer.
Here's what it looks like in practice:
client = EventSourcingDB.Client.new("http://localhost:3000", "secret")
event = %EventSourcingDB.EventCandidate{
source: "https://library.eventsourcingdb.io",
subject: "/books/42",
type: "io.eventsourcingdb.library.book-acquired",
data: %{
"title" => "2001 – A Space Odyssey",
"author" => "Arthur C. Clarke",
"isbn" => "978-0756906788"
}
}
{:ok, events} = EventSourcingDB.write_events(client, [event])
A few lines of code, and your first event is stored. No boilerplate, no ceremony, just the data and the intent.
What's Included¶
The 1.0 release covers all core EventSourcingDB capabilities. You're not getting a stripped-down subset. You're getting a fully compliant SDK that meets every item on our Compliance Criteria.
Writing events supports all four preconditions: isSubjectPristine for ensuring a subject has no prior events, isSubjectPopulated for the opposite, isSubjectOnEventId for optimistic concurrency control, and isEventQlQueryTrue for complex conditional writes using EventQL queries. You can write single events or batches, and every write supports OpenTelemetry trace context propagation.
Reading events gives you full control over ordering, boundaries, and recursion. Read chronologically or anti-chronologically, set inclusive or exclusive bounds by event ID, and use fromLatestEvent to start reading from the most recent event of a specific type. As we discussed in our post about naming events beyond CRUD, well-named events become a powerful tool for querying your history, and the SDK makes that querying flexible and efficient.
Observing events works the same way, but as a real-time stream. New events appear in your stream as they're written, which is ideal for building projections, triggering side effects, or powering real-time features. In the BEAM world, you might pipe these directly into a GenServer or a process that updates a live read model.
EventQL queries let you run analytical queries across your event store and stream the results back. Schema registration helps you enforce structure on your events. And cryptographic verification lets you check the integrity and authenticity of every event using SHA-256 hashes and Ed25519 signatures.
The SDK also includes Testcontainers support. You can spin up a real EventSourcingDB instance in your ExUnit tests, configure it with custom ports, API tokens, and signing keys, and tear it down automatically when the test is done. No mocks, no fakes, just real integration tests against a real database. If you're interested in how this fits into a broader testing strategy, our post on debugging event-sourced systems covers the mindset behind testing with real events.
From First Event to Production¶
Getting started takes less than a minute. Add the dependency to your mix.exs:
Run mix deps.get, and you're ready to go. The SDK is published on Hex.pm, so it integrates seamlessly with the standard Elixir toolchain.
If you want to explore what's possible before writing code, our Quickstart Guide walks you through writing and reading events step by step. And if you want to set up a local development environment to experiment, you can have EventSourcingDB running in under five minutes.
For full documentation, API reference, and code examples, visit the GitHub repository.
A Collaborative Effort¶
This release wouldn't have been the same without the outstanding contribution of Thomas Gossmann, who played a key role in shaping the SDK. His deep expertise in Elixir, his eye for idiomatic design, and his commitment to quality made a real difference. Thank you, Thomas, for the excellent collaboration. It's contributions like these that make building developer tools so rewarding.
EventSourcingDB Speaks Your Language¶
With this release, EventSourcingDB now offers official client SDKs for .NET, Elixir, Go, JavaScript/TypeScript, PHP, Python, and Rust, plus a partner SDK for Java. That's eight languages and platforms, each with an SDK that follows the idioms and conventions of its ecosystem. You can see the full list and compare capabilities on our Client SDKs overview page.
Our goal has always been to meet developers where they are. Event Sourcing is a powerful architectural pattern, but it only delivers value if it's easy to adopt in the stack you already use. Whether you're building a Phoenix web application, a Nerves-powered IoT device, or a distributed backend service on the BEAM, EventSourcingDB is now a natural fit.
If you'd like to explore what EventSourcingDB can do for your Elixir projects, head over to our documentation and give it a try. And if you have questions, ideas, or feedback, we'd love to hear from you at hello@thenativeweb.io.