A storage-hungry log server doesn't just cost more the day you buy it. It quietly taxes you every month — and then it fails you at the exact moment you can't afford it to. If a vendor's first answer to "what do I need?" is a stack of multi-terabyte drives, that's worth a second look.
The bill you see on day one
When a log server stores every event as a bulky row, terabytes become mandatory. That means bigger drives, more of them, and usually spinning disks instead of flash — because SSD at that capacity is expensive. So you're paying for hardware you only need because the software is inefficient. It's a cost, but it's the smallest one.
The bills you don't see
- Backups multiply. Every terabyte of primary storage is another terabyte to back up. A 16 TB log store needs a 16 TB backup target; a 200 GB store fits on media you already own.
- Search gets slow. Investigations run against big spinning disks are painful — a lawful-intercept request that should take a second turns into minutes of grinding through enormous per-day tables. Storage bloat isn't just a capacity problem; it's a speed problem.
- Growth compounds. Add subscribers or extend retention and an inefficient store grows terabytes at a time. An efficient one grows gigabytes at a time. The gap widens every month you operate.
The failure mode nobody quotes
Here's the one that actually hurts: a full disk stops your logging. When a storage-heavy server fills up — and oversized stores fill faster than anyone plans for — ingestion halts. The router keeps sending, but nothing lands. That's not an inconvenience; on a compliance log server it's a gap in the record, exactly the thing the whole system exists to prevent. We've seen it happen in the field, and the root cause is almost always the same: a store that was always going to run out because it was never efficient to begin with.
The lever is efficiency, not capacity
The fix isn't to keep buying bigger drives — it's to store each event in a fraction of the space. InfinityLog's cutting-edge storage technology compresses the same compliance data into roughly 16 bytes an event, about 8× smaller than a traditional row-store. That single change cascades through every cost above:
- Months of retention live on a small, fast SSD instead of a rack of HDDs.
- Backups become trivial because there's simply less to copy.
- Search returns in under a second because it reads only what it needs.
- The disk stops being the thing you nervously watch, because it's no longer filling.
How to size it honestly
When you compare log servers, don't compare total storage — compare storage per subscriber. Ask each vendor: for my subscriber count and my retention window, how many bytes per event do you store, and what disk do you actually require? The answer tells you whether you're buying a well-built system or subsidising an inefficient one with hardware.
The takeaway: terabytes aren't a sign of a serious log server — often they're a sign of an inefficient one. The right technology turns a terabyte problem into a gigabyte one, and takes the "will it fill up?" question off your plate for good.