EventSourcingDB 1.3.0 introduces a new v2 API that fundamentally changes how the database communicates with clients by reporting request outcomes directly in the response body rather than relying on HTTP status codes. This shift, combined with over sixty bug fixes, aims to provide a more stable and faster experience for developers building on event-sourced architectures.
The v2 API and Error Handling
The v2 API treats a request as 'accepted' only after it passes authentication, schema validation, and resource limits. Once accepted, the server returns the outcome in the body, allowing clients to read specific error codes rather than interpreting generic HTTP status codes.
Each error code serves as a direct link to a documentation page explaining the cause and the necessary fix. Additionally, the v2 API introduces recursive preconditions, such as `isSubjectPristine` and `isSubjectPopulated`, which can be applied to a subject and all its children in a tree structure.
“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.”
— EventSourcingDB 1.3.0 is Available
Performance and Stability Optimizations
Version 1.3.0 optimizes the underlying storage and query engine, making writing faster for both single and concurrent clients. It also improves EventQL query performance, specifically for operations that group, sort, or join multiple sources.
To ensure system stability, the update introduces strict resource bounds on every request, answer, and idle connection. EventQL queries are now limited by nesting depth and memory usage to prevent a single query from overflowing the stack or exhausting system memory.
Production Readiness and Migration
New production-focused features include a default rate limiter that scales with machine size and an OpenMetrics-compatible health endpoint. A new `--require-event-schemas` flag allows administrators to reject any writes or restores of events that do not have a registered schema.
Upgrading to 1.3.0 requires a full server stop because the new version locks the data directory, making a rolling update impossible. Users must also update their client SDKs before the upgrade, as 1.3.0 uses a new event hash version that older SDKs will flag as tampered data.