Artica SIEM runs as a single appliance:
The collector daemon and its ClickHouse analytics database on the same machine (physical or virtual).
This page gives you baseline requirements and shows how to size the machine according to your number of events and your retention period.
For an exact figure tailored to your traffic, use the built-in Capacity Calculator in the Artica console.
The tables below are safe starting points.
| vCPU | RAM | Disk (SSD) | Use |
|---|---|---|---|
| 2 | 4 GB | 60 GB | A single small proxy, testing, short retention |
The main driver is the sustained number of events per second.
As a reference, the engine is designed for up to ~20,000 events/s (JSON) and ~50,000 events/s (compact binary format) on a properly sized machine.
| Profile | Sustained events/s | ~ Events / day | vCPU | RAM | Disk (SSD/NVMe) | Typical use |
|---|---|---|---|---|---|---|
| Starter | up to 1,000 | ~85 million | 2–4 | 4–8 GB | 80–150 GB | Single site, one proxy |
| Standard | up to 5,000 | ~430 million | 4 | 8–16 GB | 250–500 GB | SMB: proxy + firewall, one site |
| Busy / multi-site | up to 20,000 | ~1.7 billion | 8 | 16–32 GB | 1–2 TB | Several sites, or an IT provider |
| High volume | up to 50,000 | ~4.3 billion | 16+ | 32–64 GB | 2 TB+ | Large / consolidated deployments |
RAM note:
ClickHouse benefits from RAM for merges and dashboards.
The appliance caps ClickHouse memory to protect the host, so more RAM = faster queries and larger batches, not a hard requirement to ingest.
Artica SIEM does not keep every raw event forever. Data is aged automatically in tiers, so long retention stays cheap:
| Tier | Default age | Granularity | Relative size |
|---|---|---|---|
| Raw detail (URLs, users, IPs) | first 2 hours | per event | Largest — but very short window |
| 10-minute rollups | up to 7 days | 10 min | Much smaller |
| Hourly rollups | up to 15 days | 1 hour | Tiny |
| Daily rollups | long term | 1 day | Negligible |
Because of this, going from 30 days to 6 months or a year of retention grows disk only modestly — you are mostly adding compact daily/hourly summaries, not raw events.
All thresholds are configurable.
A practical rule of thumb (SSD, compressed):
Worked example — 5,000 events/s, 180-day retention: ~5 GB hot + rollups over 6 months + headroom == plan 250–500 GB.
Double the event rate or the retention, and scale the disk accordingly.