# Rate Limiting

EventSourcingDB **limits how many requests a single client may send**, so that a client which accidentally sends far too many requests – for example because of a runaway loop – **cannot overwhelm the database**. Rate limiting is **enabled by default** and applies to the API.

## How It Works

The limit is applied **per client**, identified by the **source IP address** of the connection. This **isolates the offender**: a client that sends too many requests **exhausts only its own budget**, while every other client keeps working normally. Forwarded headers such as `X-Forwarded-For` are deliberately **not** trusted, because EventSourcingDB is meant to run in a protected network with controlled clients.

Requests are **weighted**, because writing is markedly more expensive than reading: a **write counts as several requests**, while a read counts as one. The limit you configure is therefore best understood as a budget of read-equivalent requests per second.

When a client exceeds its limit, the database responds with **`429 Too Many Requests`** and a **`Retry-After`** header that tells the client how long to wait. On normal responses, the database also sends the **`RateLimit`** and **`RateLimit-Policy`** headers, so that a cooperative client can **slow down before it is throttled** instead of running into errors.

The remaining quota in these headers is expressed in **request units**, not in plain request counts – a write consumes several units, a read one. So a remaining value of, say, `4` means a read would still pass while a write would not. The **`Retry-After`** header remains the authoritative answer to when a rejected request may be retried.

Rate limiting is **always active and not tied to your license**; it is a safeguard, not a premium feature.

## Configuring the Limit

The **defaults are deliberately conservative** and scale with the size of the machine. They are **high enough not to interfere with ordinary workloads** and **low enough to contain accidents**. For most deployments, **you should not need to change anything**.

This is an **advanced setting**. **Only change it if you understand what you are doing and what the consequences are** – setting it too high defeats the protection, while setting it too low can throttle legitimate clients.

If a legitimate workload runs into the limit, **raise it** with the `--rate-limit-requests-per-second` flag:

```shell
./eventsourcingdb run [...] --rate-limit-requests-per-second 5000
```

To **disable the per-client limit entirely**, set the value to `0`:

```shell
./eventsourcingdb run [...] --rate-limit-requests-per-second 0
```

The recommended approach is to **start with the default and raise the limit only if you actually hit it**, rather than guessing a higher value up front.

## For More Information

- To restrict who may access the database at all, see **[Security and Access Control](/docs/eventsourcingdb/v1.1/security-and-access-control)**.
- To temporarily disable writes, see **[Read-Only Mode](/docs/eventsourcingdb/v1.1/read-only-mode)**.