# Limits

This guide summarizes the **technical and licensing limits** that apply when using EventSourcingDB. It covers **maximum capacities**, **storage considerations**, and **relevant operational constraints**.

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.3)* A 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](/learn/tutorials/first-steps-with-eventsourcingdb/writing-events)** accepts a body of **up to 10 MiB**, so that a single write can carry many events.
- *(Changed in 1.1; Changed in 1.3)* **Reading 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](/docs/eventsourcingdb/v1.2/backup-and-restore)** accepts a body of **any size**, since the backup is streamed into the database.

*(Changed in 1.3)* A 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](/docs/eventsourcingdb/v1.2/read-only-mode#read-only-mode-while-the-disk-is-almost-full)**.

> **File System Constraints**
>
> Make sure the target file system supports **large files** and **sufficient storage capacity**, especially when managing millions of events over time.

## 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](/learn/tutorials/first-steps-with-eventsourcingdb/reading-events)**.

*(Changed in 1.3)* A 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.3; Broken in 1.2, fixed in 1.3)* **A 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.1; Changed in 1.3)* An **[EventQL query](/docs/eventsourcingdb/v1.2/eventql)** 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](/docs/eventsourcingdb/v1.2/eventql#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.