One Keel appliance ingests, parses, and stores in a single compiled pipeline — over 400,000 events per second, sustained, on a modest 4-vCPU node, with zero dropped events.
Sustained OTLP ingest on a single 4-vCPU node, with zero dropped events — and at full push the load generator was the bottleneck, not Keel, so this is a floor rather than a ceiling. For most teams ingestion is never the limit; you'll size the deployment by how long you keep data, not by whether Keel can keep up.
* Benchmarked for OTLP ingest on a relatively fresh table; sustained throughput declines as the hot table grows. Protocol-specific and higher-volume figures are workload-dependent — we'll walk through them for your environment.
Size on your average rate — a spike is absorbed by the node's headroom and adds almost nothing to stored volume. A 10k-average workload with 50k spikes still sits well under the single-node ceiling, absorbed with zero loss.
Keel stores a recent window on fast NVMe for instant interactive search, and ages older data to object storage where capacity is cheap and effectively unlimited. Data is partitioned by day and column-compressed, so a time-bounded query — "last hour," "last day" — scans only the days it needs and stays fast no matter how much history you hold.
Daily volume at a planning default of ~200 bytes/event (post-compression), then the NVMe needed to keep 7 / 30 / 90 days searchable on one node. Your bytes/event depends on your data — structured logs compress far smaller than free text.
| 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 |
Because history lives in cold storage, keeping a full year is a cheap object-storage line item, not a bigger SSD. At 100k EPS, a 365-day archive is on the order of ~470 TB of cold storage while the hot tier stays small — a 14-day searchable window is roughly 18 TB of NVMe on one node.
Not modeled, not extrapolated. Here's the exact setup — so you can size with confidence and reproduce it yourself.
Test hardware: a single node — 4 vCPU, 16 GB RAM, NVMe SSD. The headline figure is sustained OTLP ingest, measured with zero dropped events on a relatively fresh table; sustained throughput declines as the hot table grows.
Storage figures use post-compression bytes/event; real compression varies with data shape — structured logs compress far smaller than free text. Sustained ingest into a very large hot table declines as background compaction competes for CPU and disk-IO, so size cores and NVMe to your target hot window.
Figures are planning guidance, not contractual SLAs. Validate against a representative sample of your own logs before committing hardware — two inputs set everything: your average ingest rate and your hot-window length.
Tell us your ingest rate and retention target and we'll size a node with you — or run a POC in your environment and measure it live.
Book a walkthrough Try the live demo