SIEM Storage Sizing: How to Calculate What You Actually Need

Most SIEM sizing guides open with a table mapping endpoint counts to daily gigabytes. The table is useless, because it hides the two variables that move the answer furthest: your actual event rate, and the compression ratio you will see on your own logs. Here is how to measure both, and where those measurements go.

Measure, do not estimate

Event rate is events per second across all sources, and the only way to know it is to count. Pick a representative weekday, route your logs to a collector that timestamps and counts them, and run it for twenty-four hours. Divide the total by 86,400. That is your baseline rate. If you have no test collector, have your existing syslog server write a line count to a file every minute for a day and sum the counts. The mechanism matters less than running it long enough to catch the daily peaks.

Do not multiply endpoint counts by a per-device figure from a datasheet. Event volume varies enormously by device role, not by device count, and a quiet estimate built on the wrong role will be wrong in whichever direction hurts most.

Then measure average event size in the format your SIEM actually stores, which is after parsing and enrichment rather than as the raw line arrived. Parsing usually adds fields. Take the stored size of a day of events and divide by the event count for that day.

Compression is the number you cannot look up

Compression ratio decides how much of your raw volume ever reaches the disk, and it moves the final figure further than disk price does. It depends on your schema, your field cardinality and the codec in use, which is why no published figure can tell you yours.

Columnar stores compress security logs well because a column holds one kind of value, so the compressor sees a long run of similar data rather than a mixture. ClickHouse, which nPro uses as its datastore, applies codecs per column and supports column compression codecs chosen for the shape of the data in that column.

The only way to know your ratio is to ingest a week of your own logs and measure it. Any ratio in a vendor datasheet is a starting assumption to be replaced by your own measurement. Size against raw ingest volume instead and you will overprovision by exactly the factor you failed to measure.

The sizing formula

Start with daily raw ingest volume in gigabytes. Divide by your measured compression ratio to get the daily disk footprint. Multiply by your retention period in days. Then add headroom.

Every number in that chain except the ratio is one you already know or can decide. That is the whole argument for measuring it properly.

Headroom, and when to measure again

Two things eat headroom. Retention policy changes, usually upward and usually because somebody outside the security team asked for it. And incident spikes, where a noisy source or an active investigation lifts volume for days at a time. Provision so that neither forces an emergency purchase.

Re-measure when your estimate's inputs change rather than on a calendar. Onboarding a new log source, turning up logging verbosity, adding sites, or changing the parser all move the numbers. A sizing done once at procurement and never revisited is the one that runs out of disk.

What this means for a self-hosted SIEM

When the SIEM runs on your own infrastructure, storage is disk you buy and retention is a policy decision rather than a licence tier. Keeping a year costs you a year of disk, not a different contract. That makes the sizing exercise worth doing carefully, because the number you produce is the number you spend.

If you are earlier in the process, start with what is a self-hosted SIEM, or compare the models in cloud versus on-premise SIEM. If you are building the case internally, the MSSP on-premise SIEM business case and the SIEM implementation checklist cover what comes next.