EventSourcingDB 1.3.0 Is Available

Resources / Blog / EventSourcingDB 1.3.0 is Available Announcement November 11, 2026 6 min read EventSourcingDB 1.3.0 is Available EventSourcingDB 1.3.0 is out, and it is faster and more stable than any version before it. Writing and EventQL queries are considerably faster, reading is faster as well, every request is bounded in time, and more than sixty fixes went in. Next to all that, it brings a new API that reports the outcome of every request it accepts in its body and names every error with a code of its own. Golo Roden CTO and founder, the native web This post walks through what changed and what to mind when you upgrade. The v1 API is supported until January 31, 2027 , and a later release removes it, so you can move to the new one at your own pace. And from today on, the documentation of EventSourcingDB lives on eventfoundation.io ; every old link leads there. A New API, Built to Last # The new v2 API runs next to the v1 API, on the same data. Its central idea is simple: once the server has accepted a request, its outcome is in the body . A request counts as accepted when it is authenticated, its body has the shape its route expects, and it stays within its limits. A precondition that does not hold, an event type that is not known, a database in read-only mode – all of these come back as an answer the client can read, rather than as a status code it has to interpret. Every error carries a code that is a link to its own page , which explains why it happens and how to fix it. You will find them all under Errors . Streamed answers that come to an end, such as reading events, close with an explicit end item, so a client can tell a complete answer from one that was cut off. While a stream waits, the server sends heartbeats through it, which keeps a proxy from closing it in between. The v2 API also brings recursive preconditions : isSubjectPristine , isSubjectPopulated , and isSubjectOnEventId can now apply to a subject together with every subject below it. That is useful whenever a decision depends on a whole part of the tree rather than a single subject. The current versions of all eight client SDKs speak both APIs and use the v2 API wherever the server offers it. So apart from updating your SDK, you do not have to change your code, as long as a proxy in front of the database lets through the HTTP method QUERY , which the v2 API uses for reading. If you call the HTTP API directly, Migrating to v2 shows what changes, route by route. Moving and Backing Up Data # Exporting and importing make it easier to move events into a new database. Both work with one plain CloudEvent per line, including its ID and time, so an export imports without any conversion . Since the import computes the hashes itself, you can also export a history, remove personal data from it, and import the result without having to compute any hash by hand. Incremental backups hold only the events written since a previous backup. A restore takes a full backup followed by its increments, which keeps regular backups of a large database small. Restoring itself has become considerably faster too, since it now writes events in batches. Faster, and Sturdier Under Load # Writing is considerably faster , for one client as for many at once, and it no longer slows down as the store grows. Running EventQL queries is considerably faster as well, most of all for queries that read many events, group, sort, or join several sources, and so is reading events. The indexes take far fewer files, so reading the events of a subject gets faster in large databases, and verifying the integrity of the store reports every inconsistency it finds, up to a hundred, rather than only the first. Much of the other work in 1.3 is invisible until you need it. Every request, every answer, and every idle connection is bounded in time , so a slow or stuck client can no longer hold resources forever. EventQL queries have limits on how deeply they nest and how much memory they hold, which keeps a single query from overflowing the stack or taking as much memory as it likes. The server compares the API token in constant time and refuses to start with one that could be guessed. And if it fails to store a write, for example because the disk is full, it switches to read-only mode until it is restarted, keeps serving reads, reports this through its health endpoint, and names the cause in its log. Limits lists the bounds. Running in Production # A few additions are aimed at running EventSourcingDB in production. Rate limiting is enabled by default and scales with the size of the machine, so a single client that sends far too many requests cannot overwhelm the database. The health endpoint of the v2 API speaks OpenMetrics , which means you can scrape it with Prometheus and similar tools directly, and it reports more about the process, such as its memory and its file descriptors; Logging and Monitoring lists what it reports. If you want to make sure that only known event types are ever written, the new flag --require-event-schemas rejects writes and restores of events whose type has no registered schema. It is off by default. And an API catalog at /.well-known/api-catalog points tools to the OpenAPI documents of both APIs. Before You Upgrade # This release asks for some care when upgrading. Please read Upgrading EventSourcingDB before you start; these are the points that matter most: Back up your data first. A data directory that 1.3 has opened cannot be opened by an earlier version again, so a backup is the only way back. Stop the old server before you start 1.3. Versions up to 1.2 do not lock the data directory, so a rollout that starts the new server first, such as a Kubernetes Deployment with RollingUpdate , would run two servers on the same data, which can damage it. The Docker image runs as another user , UID 65532 instead of 100. A data directory that an earlier image wrote has to be handed over to the new user once, or the container keeps running as the old one; the guide shows both, for Docker and for Kubernetes. The API token needs at least 32 characters , unless the server runs with a temporary data directory, and it has to be printable ASCII without whitespace at its start or end. Otherwise, the server refuses to start. Update your client SDKs first if your applications verify event hashes, since 1.3 writes a new version of the event hash, and older SDKs report every event written after the upgrade as tampered with. The flags --ai-model and --ai-option are gone , since EventAI leaves the management UI; a server that is still started with them no longer starts. Check your EventQL queries and preconditions : 1.3 changes, among other things, how values of different types compare, treats the ID of an event as a string, and takes dates and times in UTC, which can change their results or make them fail. The first start rebuilds the indexes : 1.3 starts right away and serves reads and writes, but refuses EventQL queries and a few other requests until it is done, which can take several minutes. The upgrade guide and the changelog list everything else that needs attention, such as stricter rules for the source of events and for event schemas. Time to Upgrade, or to Start # Faster where it counts, sturdier where things go wrong, and with a new API next to the one you know: that is 1.3. If you are already running EventSourcingDB, the upgrade guide gets you there safely. And if you have not tried EventSourcingDB, the database built for Event Sourcing, this is a good moment to start. Installing EventSourcingDB gets you the binaries and the Docker image, and the Quickstart takes you from starting the server to writing and reading a first event in a few minutes. We'd love to hear what you build with it. Filed under Announcement Remembering EventSourcingDB Share Copy link Share… Written by Golo Roden CTO a