Performance & Sizing¶
This page gives measured single-node throughput and a simple model for sizing a Keel deployment. Figures are planning guidance, not contractual SLAs — validate against a representative sample of your own log data before committing hardware.
Measured single-node throughput¶
On a single node (4 vCPU, 16 GB RAM, NVMe SSD), Keel sustains over 400,000 events/sec of OpenTelemetry (OTLP) ingest with zero dropped events — and at full push the load generator, not Keel, was the bottleneck, so this is a floor, not a ceiling.*
* Measured on a relatively fresh table; sustained throughput declines as the hot table grows. Protocol-specific figures (syslog, JSON, logfmt) are workload-dependent and available on request.
For most deployments, ingestion is never the limit — you'll size by how long you keep data searchable, not by whether Keel can keep up. A spike is absorbed by the node's headroom and adds negligibly to stored volume; size on your average rate.
The sizing model¶
Two inputs determine everything: your average ingest rate and how many days you keep data hot (on fast disk).
bytes_per_event is the post-compression size on disk, which depends on your data:
- ~60 B — highly structured / repetitive JSON
- ~200 B — typical mixed application + infrastructure logs (planning default)
- ~400 B — verbose free-text / high-cardinality
Data is partitioned by day and column-compressed, so a time-bounded query (for example "last hour" or "last day") scans only the days it needs and stays fast regardless of how much total history you hold.
Hot-tier footprint by retention¶
Daily volume at the ~200 bytes/event planning default, and the fast disk needed to keep 7 / 30 / 90 days searchable on one node. Substitute your own bytes/event to re-scale.
| Ingest (avg) | Events / day | Volume / day | 7 days hot | 30 days hot | 90 days hot |
|---|---|---|---|---|---|
| 10k EPS | 864 M | 173 GB | 1.2 TB | 5.2 TB | 15.6 TB |
| 50k EPS | 4.3 B | 864 GB | 6.0 TB | 26 TB | 78 TB |
| 100k EPS | 8.6 B | 1.73 TB | 12 TB | 52 TB | 155 TB |
Hot & cold tiering¶
Keel keeps a recent window on fast NVMe for interactive search and ages older day-partitions to S3-compatible object storage, where capacity is cheap and effectively unbounded.
Because history lives in cold storage, keeping a full year does not grow the hot tier — it's an object-storage line item, not a bigger SSD. For example, at 100k EPS a 365-day archive is on the order of ~470 TB of cold storage while a 14-day searchable hot window is roughly 18 TB of NVMe on one node.
What to provision for¶
- Time-scoped search stays fast at any table size (day-partition pruning).
- Sustained ingest into a very large hot table competes with background compaction for CPU and disk I/O — give the node adequate cores and NVMe for your target hot window.
- Keep ≥ 25–30% of the hot disk free for compaction headroom.
Methodology
The headline figure is sustained OTLP ingest, measured with zero dropped events on a relatively fresh table. Storage figures use post-compression bytes/event; real compression varies widely with data shape — structured logs compress far smaller than free text. Validate against your own data before committing hardware.