Why Log Retention Got Expensive in 2026 | nPro

Enterprise flash costs roughly six and a half times what it did a year ago. A 30TB TLC drive that listed at $3,460 in the third quarter of 2025 lists at $22,600 now. That is not a rounding error on a line item nobody watches. For teams retaining security logs, it is the difference between a retention policy set by compliance and a retention policy set by procurement.

What actually happened

The cause is not a factory fire or a shipping problem. Samsung, SK Hynix and Micron have been moving production capacity toward high-bandwidth memory and high-density enterprise SSDs, because AI infrastructure buyers pay more for them. Enterprise SSD margins run at 25 to 40 per cent against 5 to 15 per cent for client drives, so the reallocation is rational and it is not temporary. VDURA, whose Flash Volatility Index tracks this, calls the new pricing structural rather than a spike.

30TB drive	Q3 2025	Q3 2026	Per TB now
Enterprise TLC SSD	$3,460	$22,600	$753
Enterprise QLC SSD	$2,768	$18,080	$603
Enterprise HDD	$495	$1,216	$41

Flash rose another 5 per cent in July 2026, which counts as stabilisation compared with the first quarter. The TLC to HDD multiple peaked at 23.2× in Q1 and has eased to 18.6×. Nobody is forecasting a return to 2025 prices.

Why this lands on log retention first

Most workloads have a working set. Log retention does not. It is a volume multiplied by a time window, and the time window is usually set by someone outside the engineering team: an auditor, a regulator, an insurer. You cannot shrink it by being clever, and it only ever grows.

So when the price per terabyte moves by a factor of six, retention is where it shows up first and hardest. And it exposes an uncomfortable fact about how most log platforms are sized: the bill is set by two numbers, and only one of them is an architectural choice.

• Bytes per day. Set by your estate and your logging policy. You can reduce it, but only by logging less, which is the decision that creates blind spots.
• Compression ratio. Set by how your storage engine represents the data. Nothing about your estate changes. This is the one that is actually in your control.

What compression is worth now

ClickHouse published a benchmark on 66.75 million nginx log entries, 20GB raw. Gzip brought it to 641MB, about 31×. ZSTD at level 3 reached 522MB, about 38×. Loading the same data into ClickHouse as a columnar table with appropriate types, low-cardinality dictionaries and ZSTD codecs, ordered by timestamp as you would in production, produced 380.82MB. That is 52.71×. Ordering the same data for compression rather than for query patterns reached 109.12MB, or 178.49×, though that ordering makes time-filtered queries worse and is not what you would deploy.

Two honest caveats. Those are web access logs, which are highly repetitive and compress unusually well. And nPro's own documentation claims roughly 10:1 on security log data, which is a much more conservative figure than ClickHouse's benchmark, for a different and messier data shape. Treat 10:1 as the number to plan against and anything above it as upside.

Even at 10:1, the arithmetic is worth doing. Take a mid-sized estate producing 5,000 events per second at roughly 1KB per event, which is about 410GB of raw log a day, and hold it for 90 days:

Those are single-drive list prices before redundancy and before the rest of the server. Mirror or replicate and multiply accordingly.

The part that argues against self-hosting

If you run your own log platform, the flash price is now your problem rather than a line inside somebody's per-gigabyte rate. That is a genuine argument against self-hosting and it would be dishonest to skip it. ClickHouse is columnar, so disk throughput is the primary constraint, and both ClickHouse and nPro recommend SSD rather than spinning disk. You cannot simply buy HDD and pocket the difference.

What you can do is stop treating all retention as equal. ClickHouse supports hot, warm and cold tiers with TTL rules that move ageing parts onto slower disks automatically. Recent data, which is what incident response actually queries, stays on flash. The ninety-day compliance tail, which gets read during audits and almost never otherwise, moves to HDD at $41 per terabyte instead of $753. That is not a workaround, it is how the engine is designed to be operated, and in this market it is worth configuring on day one rather than when the disks fill.

Per-gigabyte platforms charge on both meters

Hosted SIEM pricing usually meters ingestion, and often meters retention separately. Splunk's own pricing documentation describes Ingest Pricing as "pricing based on gigabytes of data ingested into Splunk". Azure Monitor Log Analytics, which is what Microsoft Sentinel bills through, charges per gigabyte ingested and per gigabyte retained, with commitment tiers starting at 100GB a day and a useful detail buried in the docs: the billable size is typically about 25 per cent less than the incoming JSON, because standard columns are excluded.

In fairness, per-gigabyte is not the only model on offer. Splunk also sells Entity Pricing, based on monitored hosts and devices, with ingestion unmetered. So "per device rather than per gigabyte" is a pricing choice rather than something only self-hosted tools can do. The difference is what happens underneath: on a hosted platform your compression ratio is the vendor's business and you never see it, whereas self-hosted it is a schema and codec decision you can measure and change.

What to do this quarter

1. Measure your actual compressed size per day rather than trusting a planning ratio. Both numbers matter and only one is usually written down.
2. Separate your incident-response window from your compliance tail, and price them differently. They have completely different access patterns.
3. Configure TTL tiering before you need it. Retrofitting storage policies onto a full cluster is unpleasant.
4. If you are buying flash this year, factor the lead time. Twenty to thirty weeks changes project planning, not just budgets.
5. Check what your current platform charges for retention as distinct from ingestion. On some bills they are separate lines and only one gets scrutinised.

Do not self-host because of this

If your current SIEM works, your retention is not under budget pressure, and you have nobody who wants to own a database, then a flash price move is not a reason to change architecture. Migrations cost engineering quarters, and a bad self-hosted deployment is worse than a good hosted one. The argument in this piece is narrower than it might look: storage economics changed sharply, compression ratio is now the variable that matters most for retention cost, and if you self-host it is a variable you can see and act on.

nPro stores XDR, SIEM and network monitoring data in a single ClickHouse backend on your own infrastructure. The architecture and sizing guidance covers the storage model, and pricing is per agent rather than per gigabyte, so the retention decision and the licence decision stay separate.

---

Sources

• StorageReview, on VDURA's Flash Volatility Index, for the Q3 2025 and Q3 2026 drive prices and the TLC to HDD multiple.
• Silicon Analysts, for the capacity reallocation, margin figures and lead times.
• ClickHouse, compressing nginx logs, for the 52.71× and 178.49× benchmark figures.
• ClickHouse sizing and hardware recommendations, for disk guidance and hot, warm and cold tiering.
• Splunk pricing models, for Ingest Pricing and Entity Pricing.
• Azure Monitor logs cost calculations, for per-gigabyte ingestion and retention and the billable size note.