Vestigo sizing calculator
What a Vestigo deployment needs, from what you expect to put in it. Everything below is
computed with the same arithmetic src/vestigo/db/_scan.py uses at runtime —
the constants are generated from the source, not transcribed.
Every value comes in two columns. Minimum is the smallest configuration that
still serves the workload you described. Max for your hardware spends the
machine you actually have: as many scan slots as its cores and RAM support without shrinking a
query below the size a whole-corpus GROUP BY needs.
What you expect
Events in the biggest single timeline an analyst will scan. Detectors read the whole thing, so this is what sizes ClickHouse — not your total across cases.
People with the Investigate surface open at the same time. Each open timeline fires several detector sweeps at once.
Decides whether the app, Postgres and Qdrant are competing for the same RAM as ClickHouse.
Without embeddings, Qdrant needs no RAM at all. Enrichment rewrites a whole partition and takes a scan slot, so it wants the per-query cap not to be tiny.
What you have
The RAM on the machine you actually have. On the split shape, the ClickHouse host's RAM — the other services are elsewhere.
Cores ClickHouse can use. Every admitted scan wants at least
2 of them, which is what bounds how many may run at once.
What to provision
| Memory | Minimum | Max for your hardware | Why |
|---|
Settings to set
| Key | Minimum | Max for your hardware | Why |
|---|
These are starting points. The only authority on what actually resolved is
GET /api/health's scan_budget block on the machine you deploy to —
also rendered on the admin Settings page, above the Scans group. It reports the
ceiling ClickHouse really has, the caches counted against it, and a risk verdict.
Set the numbers below, start the stack, then read that.
Full reasoning, the three ceilings and how they must relate, and worked examples: docs/DEPLOYMENT.md §Resource sizing. Scan-cost machinery: docs/ANOMALY_DETECTION.md.