EPS to GB conversion for SIEM pricing: 2026 tables and worked examples
Independent reference for converting between Events Per Second and gigabytes per day across SIEM vendor pricing models. Interactive EPS-to-GB calculator, per-source conversion tables, three worked examples, and the discipline that prevents wrong vendor decisions. Updated September 2026.
There is no fixed EPS-to-GB ratio: it depends entirely on your log source mix. A mixed-enterprise environment averages roughly 70-100 events per second per GB per day (midpoint about 85 EPS/GB); network-heavy mixes run 200-400 EPS/GB and verbose cloud-audit logs run 30-50 EPS/GB. Enter your own figures in the calculator below, or use the reference table for a first-pass estimate at the 85 EPS/GB midpoint.
Modelled at the 85 EPS/GB mixed-enterprise midpoint (GB per day multiplied by 85). Your real ratio varies 30-50 percent with source mix; sample 30-60 days before any vendor sizing.
Percentages are each source's share of total GB ingested. Need not sum to 100; the ratio is normalised.
The conversion problem
SIEM vendors split into two pricing camps based on the underlying cost driver of their architecture. Per-GB-priced SIEMs (Splunk, Microsoft Sentinel, Datadog, Devo, CrowdStrike LogScale) meter on data volume because their analytics engines scale with bytes processed; Sumo Logic's Flex model is the exception, billing scan and storage rather than ingest. Per-EPS-priced SIEMs (IBM QRadar, Securonix, LogRhythm via MPS) meter on event rate because their correlation engines scale with events per second. Both models are honest reflections of what costs money on the vendor side, but they make cross-shop comparisons require a conversion step.
The conversion is not a constant. EPS measures the rate of events per second; GB measures the volume of bytes ingested. The two correlate loosely but not tightly because event size varies enormously by source. A Windows security event log entry runs 1-2 KB on average; an AWS CloudTrail JSON event runs 5-15 KB; a firewall log entry runs 200-500 bytes; a NetFlow record runs 100-300 bytes. The same data volume in gigabytes produces wildly different event counts depending on which sources dominate the mix.
The practical effect is that customers comparing vendors based on assumed conversion ratios routinely get wrong answers by 30-50 percent in either direction. A network-heavy environment shopping per-EPS QRadar against per-GB Splunk based on a 100 EPS-per-GB conversion (the rough mixed-enterprise average) will materially under-buy QRadar capacity and over-buy Splunk capacity. The reverse profile (cloud-native, JSON-heavy) will produce the inverse error. The conversion discipline matters because the vendor decision frequently turns on it.
Per-source EPS-to-GB conversion table
| Log source | EPS per GB | Notes |
|---|---|---|
| Windows Event Log (security) | 60-80 EPS / GB | Includes login, audit, system events |
| Windows Event Log (verbose / debug) | 200-350 EPS / GB | Service Control Manager spam, debug |
| Linux syslog (production) | 70-120 EPS / GB | Standard syslog facility output |
| Firewall (perimeter) | 200-400 EPS / GB | Per-rule logging, allow + deny |
| NetFlow / sFlow / IPFIX | 300-600 EPS / GB | Per-flow records, very high event rate |
| Cloud-trail (AWS CloudTrail) | 40-80 EPS / GB | Verbose JSON, low EPS, high GB |
| Azure Activity Log | 40-70 EPS / GB | Similar verbose JSON pattern |
| Microsoft 365 audit | 30-50 EPS / GB | Detailed audit records, low EPS |
| EDR telemetry (CrowdStrike, SentinelOne) | 100-150 EPS / GB | Process trees, file events |
| DNS query logs | 400-700 EPS / GB | Very high event rate, small per-event |
| Web proxy / SWG | 150-250 EPS / GB | Per-request logging |
| Database audit (SQL Server, Oracle) | 80-140 EPS / GB | Per-transaction audit records |
Typical observed ratios across enterprise environments. Real-world variance of 30-50 percent in either direction is common. Use as first-pass reference, not as substitute for actual sampling.
Three worked examples
Mid-market with mixed sources
Source mix: 60% Windows event (~70 EPS/GB), 20% firewall (~300 EPS/GB), 10% MS365 (~40 EPS/GB), 10% EDR (~125 EPS/GB)
Weighted ratio: ~120 EPS / GB total
A 50 GB-per-day environment ingests roughly 6,000 EPS sustained. Splunk at 50 GB per day plus Enterprise Security runs roughly $100K all-in (about $50K base ingest, which ES roughly doubles), and that figure does not move when the event rate does. QRadar cannot be put on the other side of that line: IBM publishes no per-EPS rate, and the only public QRadar price is an AWS Marketplace contract covering 500 EPS, twelve times smaller than this profile. What the conversion does tell you is the direction of travel. At 120 EPS per GB this mix is event-dense, so an event-rate meter bills you for the same 50 GB more heavily than a byte meter does. Get IBM to quote 6,000 EPS and compare it against the $100K yourself.
Cloud-native engineering team
Source mix: 60% AWS CloudTrail (~60 EPS/GB), 15% MS365 (~40 EPS/GB), 15% EDR (~125 EPS/GB), 10% Linux syslog (~95 EPS/GB)
Weighted ratio: ~70 EPS / GB total
A 50 GB-per-day environment ingests roughly 3,500 EPS sustained. Splunk at 50 GB per day plus Enterprise Security runs roughly $100K all-in (about $50K base ingest, which ES roughly doubles). We will not put a QRadar number beside it, because IBM publishes none and the one public QRadar contract covers 500 EPS, a seventh of this profile. Structurally this is the mix that flatters an event-rate meter: at roughly 70 EPS per GB the events are large and comparatively few, so the event-rate axis is working in your favour rather than against it. That makes it the profile most worth getting an IBM quote for, and the choice then turns on content depth and source mix rather than a price win either way.
Network-heavy / regulated finance
Source mix: 50% firewall (~300 EPS/GB), 25% NetFlow (~450 EPS/GB), 15% Windows event (~70 EPS/GB), 10% DNS (~550 EPS/GB)
Weighted ratio: ~330 EPS / GB total
A 50 GB-per-day environment ingests roughly 16,500 EPS sustained. Splunk at 50 GB per day plus Enterprise Security runs roughly $100K all-in, and that figure is unchanged by the event rate. This is the profile where the two meters diverge hardest: at roughly 330 EPS per GB you are pushing thirty-three times the event count of the 500 EPS footprint IBM has publicly priced, on the same 50 GB. We cannot tell you what IBM will charge for that, and we will not guess, but a per-EPS meter is structurally the wrong shape for a network-heavy mix and this is the case to price carefully before committing.
The discipline that prevents wrong vendor decisions
Sample your environment for 30-60 days before any vendor sizing conversation. Modern SIEMs (any of the vendors listed in our pricing pages) provide native EPS and GB-per-day metering at the source level, free of charge during evaluation. Many environments already have this data available from an existing log management tool, even if the SIEM purchasing decision is brand-new. Without 30-60 days of source-level data, every vendor sizing conversation is based on assumption rather than measurement, and assumptions in this domain routinely produce wrong vendor decisions.
Calculate the weighted-average EPS-to-GB ratio across your real source mix. The math is straightforward once the sampling exists: for each major source, multiply its observed EPS by its observed GB-per-day, sum the products, divide by total GB-per-day. The resulting ratio applies to your specific environment and replaces the rough mixed-enterprise average that vendor pre-sales materials routinely use.
Apply the ratio in both directions when cross-shopping. Per-EPS vendor quotes get converted to per-GB equivalents using your environment's actual ratio; per-GB vendor quotes get converted to per-EPS equivalents using the inverse. The honest comparison shows where each vendor sits on cost in your specific environment, not in a generic environment that does not exist. Vendors that claim to be cheapest at the headline rate frequently are not cheapest in your specific source mix; vendors that look uncompetitive at the headline rate frequently win once the conversion is applied honestly.
Finally, never accept a vendor's own conversion ratio without sourcing it back to your actual environment data. Splunk pre-sales materials assume per-EPS conversion rates that overstate Splunk's competitive position; QRadar pre-sales materials assume rates that overstate QRadar's. The conflict of interest is real and unavoidable. The honest conversion is the one calculated from your data, not from any vendor's marketing.