Limits

EventSourcingDB is designed to handle large volumes of events and subjects efficiently. However, some practical and licensing limits apply. This page provides an overview of these limits to support planning and system sizing.

Event Limits#

The number of events that EventSourcingDB can store is subject to both licensing and technical limits:

• Licensing Limit: Evaluation licenses allow up to 25,000 events. Commercial licenses remove this restriction.
• Technical Limit: The absolute maximum number of events is 9,223,372,036,854,775,807, corresponding to the largest value representable by a signed 64-bit integer.

In practice, the technical limit is extremely large and will not be reached under normal operational conditions. Most deployments are constrained by license terms and available disk space.

Subject Limits#

EventSourcingDB does not impose a strict technical limit on the number of subjects. Subjects are stored efficiently, and their number is practically bounded only by the total event volume and available storage.

Event Type Limits#

EventSourcingDB does not impose a strict technical limit on the number of event types. Event types are managed efficiently, and their number is practically bounded only by the overall event volume and available storage.

Size Limits#

Changed in 1.3A single event may take at most about 68 KiB, measured as it is stored, including its hash. A write that contains a larger event fails with 500 Internal Server Error, and none of its events is stored.

The bodies of requests are limited as well:

• Writing events accepts a body of up to 10 MiB, so that a single write can carry many events.
• Changed in 1.1Changed in 1.3Reading and observing events, running EventQL queries, reading subjects, reading an event type, registering an event schema, and reading the audit history accept a body of up to 100 KiB.
• Restoring a backup accepts a body of any size, since the backup is streamed into the database.

Changed in 1.3A body that exceeds its limit is rejected with 413 Content Too Large.

Storage Limits#

The storage capacity is primarily determined by the underlying file system and available disk space. EventSourcingDB itself imposes no internal maximum size on the event store. It keeps 1 GiB of the file system free, though, and refuses writes once less than that is left, as described in Read-Only Mode.

Operational Limits#

When reading events via the HTTP API, EventSourcingDB streams the result continuously. There is no internal limit on the number of events returned. In principle, the entire event history can be streamed in a single request.

If a network interruption occurs during streaming, clients can resume reading from the last successfully received event by using the lowerBound parameter. For more information on how to resume event streams, see Reading Events.

Changed in 1.3A stream waits up to 10 seconds for its client to take in each line. A client that stops reading for longer, for example because it processes a single event for that long, loses the connection.

Removed in 1.3Broken in 1.2, fixed in 1.3A request without a body that takes longer than five seconds breaks its connection, such as verifying the store, creating a backup, or listing the event types of a large store. Its answer ends incomplete, and every later request on the same connection starts as if its client had gone: reading events and listing subjects or event types answer with an empty 200, and observing events ends at once. A client that reuses its connections, as the client SDKs do, can thus miss events that are stored; nothing is lost in the data directory.

Changed in 1.1Changed in 1.3An EventQL query holds at most 1,000,000 rows at once in each part that holds rows in memory, such as an ORDER BY that sorts them, and fails beyond that, as described in Rows Held in Memory.

The headers of a request may take at most 1 MiB together. EventSourcingDB answers a request with larger headers with 431 Request Header Fields Too Large, before any route sees it.

Best Practices#

• Monitor available disk space regularly.
• Plan license upgrades in advance if approaching license-based event limits.
• Implement chunked reading for large event queries to avoid transport overhead.

Understanding system limits helps ensure smooth operation and scalability as your event store grows.