EventSourcingDB 1.3.0 delivers faster writes, bounded requests and a new outcome-reporting v2 API

EventSourcingDB 1.3.0 ships

EventSourcingDB 1.3.0 was announced on November 11, 2026, and according to the post on the project's blog, the new version is faster and more stable than any release before it. Writing and EventQL queries got the largest speed-ups, reads improved as well, and the release absorbs more than sixty fixes. The announcement says writes no longer slow down as the store grows, and the on-disk indexes need far fewer files, which speeds up reading a subject's events in large databases. The same release introduces a v2 HTTP API that reports the outcome of every accepted request in the response body, and the documentation now lives on eventfoundation.io.

Stability through hard bounds

Much of the engineering in 1.3.0 is defensive. Every request, response and idle connection now carries a time bound, so a slow or stuck client can no longer pin resources indefinitely. EventQL queries have caps on nesting depth and memory use, preventing a single query from overflowing the stack or taking unbounded memory. Integrity checks now list every inconsistency they find, up to one hundred, instead of stopping at the first.

Failure handling is more explicit too. If a write cannot be stored — a full disk, for example — the server switches to read-only mode, keeps serving reads, surfaces the condition on its health endpoint and logs the cause. API tokens are compared in constant time, and the server refuses to start with a token weak enough to guess.

The v2 API puts outcomes in the body

The v2 API runs alongside v1 on the same data. Its organizing principle: once a request is accepted — authenticated, correctly shaped and within limits — its outcome arrives in the body. A failed precondition, an unknown event type or a read-only database all come back as machine-readable answers rather than status codes the client must decode, and each error carries a code that maps to a documentation page explaining the cause and remedy.

Streamed responses such as event reads close with an explicit end marker, so clients can tell a complete stream from a severed one, and the server sends heartbeats while a stream is pending so proxies do not close it. Preconditions also gained recursion: isSubjectPristine, isSubjectPopulated and isSubjectOnEventId can now apply to a subject together with everything beneath it, which matters when a decision depends on an entire subtree.

All eight client SDKs speak both APIs and default to v2 where the server offers it, so most applications need only an SDK update — provided any proxy in front of the database passes the HTTP QUERY method the new API uses for reads. v1 remains supported until January 31, 2027.

Data movement and production defaults

Export and import use one plain CloudEvent per line, including ID and timestamp, so an export re-imports without conversion. Since the importer computes hashes itself, operators can export a history, scrub personal data and re-import without recalculating hashes by hand — a quietly useful property for privacy-driven redaction. Incremental backups capture only events written since the previous backup, and restores are faster because events are written in batches.

On the operations side, rate limiting is on by default and scales with the machine, the v2 health endpoint speaks OpenMetrics for direct Prometheus scraping and reports process details such as memory and file descriptors, and a new --require-event-schemas flag (off by default) rejects writes of event types lacking a registered schema. An API catalog at /.well-known/api-catalog points tools at the OpenAPI documents of both APIs.

Upgrading carries real risks

The announcement is frank that this upgrade needs preparation. A data directory opened by 1.3 cannot be reopened by an earlier version, so a backup is the only way back. The old server must be stopped first: releases up to 1.2 do not lock the data directory, so a Kubernetes rolling update could run two servers on the same data and damage it. The Docker image switches from UID 100 to 65532, requiring a one-time ownership transfer. Because 1.3 writes a new version of the event hash, apps that verify hashes must update their SDKs first or every post-upgrade event will look tampered with. The --ai-model and --ai-option flags are gone and will block startup, API tokens must now be at least 32 printable ASCII characters, EventQL comparison semantics changed (event IDs are strings, dates and times are UTC), and the first boot rebuilds indexes while refusing EventQL queries for what can be several minutes.

Why it matters

The v2 API's core design — outcomes in the body, named error codes, explicit stream terminators, heartbeats — attacks a chronic weakness of HTTP APIs, where status codes carry domain meaning ambiguously, and it is a pattern other API designers may well copy. The operational hardening, from time-bounded requests to graceful read-only degradation and default rate limiting, is the unglamorous work that separates production-grade databases from demos. At the same time, the irreversible data format and new event hash show the project is willing to break compatibility now, while its user base is still small, rather than carry compromises indefinitely — and the January 2027 v1 deadline gives operators a firm but generous migration clock. For teams evaluating event-sourcing infrastructure, the redaction-friendly export and import loop may be the sleeper feature of this release.