Sizing

What your estate actually generates.

Count the things that emit telemetry and this page returns events per second, ingested volume, the plan it fits if we host it, and the node shape and storage it lands in if you host it — for your retention and compliance period. Constants are measured where marked and planning defaults elsewhere; a 7–14-day pilot measures your real numbers (the platform meters itself).

This sizes the volume meter — GB/day ingested. Identity, Protect, Observability and Posture meter on seats, nodes and hosts; this page counts those dimensions for you but does not price them. See how every line is sold →

Planning levers

Peak and growth size the hardware; retention sizes the storage you buy.

Keep the raw copythe verbatim original as a sealed field — the biggest single lever, it roughly halves or doubles volume
High availabilitywarm standby per Core node (doubles node storage)

The other dimensions your estate implies

Counted from what you typed, plus one honest input. These lines meter on their own dimensions and have no published rate — so this page counts them and does not price them.

◌ no published rate
Protect · nodes enforced
—
◌ no published rate
Observability · hosts
—
◌ no published rate
Posture · nodes assessed
—
◌ no published rate

Your estate

—
events / second (average)
—
events / day
—
ingested — the plan dimension
—
stored in the lake (v2 segments)
— 

On SaaS (we host it)

—
—
You deploy—
Egress to the ingest edge—
Your compute / storage / platform opsnone — in the plan

Ingestion above the Cloud allowance is charged per GB/day at your rate card, averaged across the billing window — a one-day spike never shocks the bill.

Region-pinned pooled cell by default; dedicated single-tenant cells (own VPC, PrivateLink) for regulated estates — the deployment-models note is not published yet; ask us for it.

See what the pack holds

On-premise (you host it)

Licence tieron-prem ceiling, TB/day ingested—
Core nodes (cells)——
Each node—
Instance class—
Store NVMe—
Compliance archive—
Replay RTO per node—

—

Assumptions & constants (v2 · 2026-09-01 — planning defaults, measured where marked)
Event size (wire, raw ON / OFF)1,475 / 903 B measured
Event size (stored v2, raw ON / OFF)1,047 / 538 B measured
Per-family sizes in inventory modemeasured per source family
Compute1,500 EPS / vCPU (+2 floor, min 4)
RAM8 GB + hot-window (3.5 KB/event) + 2 GB/10k EPS
Disk overhead / archive compression×1.44 / ÷3 (gzip measured 4.3×)
Per-Core-node planning envelope10,000 avg EPS → shard into cells
Platform's own events+3 % EPS
Boot-replay rate (RTO math)5,000 events/s measured (real boot, derated)

Constants are measured on the real event + sealed segment-store path and mirror the platform's own sizing & capacity guide §12; the published reference set is listed on Resources. The formal per-node capacity target is an open engineering ratification — these defaults deliberately derate measured ceilings. Not legal advice; your compliance team owns the retention period.

Scope & Honest Limits Four planning boundaries on this calculator Expand · Full ledger →
It is a planning estimate, not a quote

The per-event sizes are measured, the events-per-second defaults are judgement. Two estates with identical hardware can differ widely on audit policy alone.

Sizing gives the volume, not the bill

This gives you the volume, not the amount. The platform line’s prices are on the pricing page; the other product lines are quoted against your own figure.

Above a certain load it shards

One Core node is planned to about 10,000 average events per second. Past that the calculator divides the estate into identical cells.

The archive is yours to place

The archive figure is compressed roughly threefold and holds the balance of your compliance period beyond what stays searchable on the node. Where it lives, and what restoring from it takes, are yours to plan.

Next step
Turn this volume estimate into a plan or a 30-day evaluation.