Limits and defaults
Server limits and their defaults. Every one is a flag; see Configuration for the matching CELERIANT_ environment variables.
| Limit | Default | Flag |
|---|---|---|
| Max client request size (compressed and uncompressed) | 16 MiB | --max-request-size |
| Max response size | 64 MiB | --max-response-size |
| Max inter-node request size | 64 MiB | --internode-max-request-size |
| Max requested watch latency | 2000 ms | --max-requested-latency-ms |
| Max watch subscribers (per shard) | 16384 | --max-watch-subscribers |
| Max schema definition size | 16 KiB | --max-schema-size-bytes |
| List page size | 2000 entities | --list-page-size |
| Max list scan duration | 2000 ms | --list-max-duration-ms |
| Max concurrent list operations (per shard) | 16 | --list-max-concurrent |
| Max concurrent backward metablock scans (per shard) | 64 | --read-max-concurrent |
| Max TLS handshakes in flight (per shard, per port) | 8 | --handshake-concurrency |
| Inter-shard channel size | 8192 | --mesh-channel-size |
| Slow-client / idle timeout | 30 s | --client-connection-timeout-ms |
| Max open files (per shard) | 1000 | --max-open-files |
| WAL file size | 1 GiB | --shard-log-preallocate-bytes |
| Cache memory | 80% of detected memory | --memory-consumption-percent |
Fixed by the protocol
These are not flags.
- Fixed-size requests: 1007 bytes. Read, details, trim, delete, watch, list and Identify bodies must fit in one 1024-byte frame. A delete naming many aggregates or a watch with large filter sets hits this first. See Wire protocol.
- Identify nonce window: at most 2 minutes old, at most 60 s in the future.
- Compression threshold: variable-size bodies under 1024 bytes are sent uncompressed.
- Aggregate versions are 1-based. An
expected_versionof 0 asserts the aggregate has no events yet, for a conditional create.
Fixed at first start
The server records these in the data root on first start and refuses to start if they later change:
- Shards:
--num-shards, default the CPU count. - Routing rule:
--routing-rule, defaultaggregate_id. - Timestamp precision:
--timestamp-precision, defaultmilliseconds;microsecondsandnanosecondsalso available.--timestamp-epoch-offset-secstoo. - Coordinator shard:
--reserve-coordinator-shard. - WAL compression:
--wal-compression-level(default 3) and--wal-dictionary-name.
Client defaults
The clients cap requests on their own side, below the server's value.
| Setting | .NET CeleriantPoolOptions | Rust PoolOptions |
|---|---|---|
| Max request size | MaxRequestSize 10 MB (10,000,000 bytes) | max_request_size 10 MB |
| Size checked on | 0.8.0: compressed length only; 0.9.0: uncompressed and compressed | uncompressed and compressed length |
| Max response size | MaxResponseSize 64 MiB | max_response_size 64 MiB |
| Connect timeout | ConnectionTimeout 5 s | connection_timeout 5 s |
| Request timeout | RequestTimeout 30 s | request_timeout 30 s |
| Idle eviction | IdleTimeout 25 s | idle_timeout 25 s |
| Connections per node | MaxConnections 10 | max_connections_per_node 10 |
A default .NET or Rust client rejects writes between 10 MB and 16 MiB that the server would accept; raise MaxRequestSize or with_max_request_size. Rust checks the uncompressed length before sending, as the server does, so compression never lets a request past the cap. The published .NET 0.8.0 checks only the compressed length, so a payload that compresses under 10 MB but expands past 16 MiB dies at the server as a dropped connection; 0.9.0 (unreleased) checks the uncompressed length too. Idle eviction sits under the server's 30 s idle timeout on purpose. See Clients.
There is no fixed cap on the number of aggregates or events.