# 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**.

## 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.

> **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)**.

## 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.