It's the single question that decides your log-server hardware bill — and the one most vendors answer with a scary round number instead of the math. Quote you 10 TB of disk and the invoice takes care of itself. Here is the actual calculation, so you can size storage on your traffic instead of someone's spec sheet.
What actually drives the number
Log storage isn't driven by how many subscribers you have — it's driven by how many events they generate. Every NAT translation, every connection your router logs, is one record. A typical broadband subscriber produces on the order of 3,000–4,000 logged events a day. So the real formula is simple:
- Daily events = subscribers × events-per-subscriber-per-day
- Daily storage = daily events × bytes-per-event
- Total storage = daily storage × retention days
Two of those three numbers are fixed by your network. The one a vendor actually controls — the one that separates a 2 TB server from a 16 TB one — is bytes per event. That's where the technology choice lives.
The expensive way: a fat row per event
Older log servers store every event as a bulky database row or a line of text — timestamp, source IP, translated IP, ports, protocol — wrapped in per-row overhead and indexes. In practice that lands around 130–180 bytes per event on disk. Run the math for a modest 20,000-subscriber network:
- 20,000 subs × 3,500 events = 70 million events/day
- 70M × 150 bytes ≈ 10.5 GB/day
- Six months of retention ≈ 1.9 TB — and that's before backups, indexes and headroom
Now you see where "you'll need a 10 TB drive" comes from. Add a bigger customer base or a longer retention window and the requirement balloons into double-digit terabytes fast. It isn't that your network is enormous — it's that each event is being stored inefficiently.
The efficient way: cutting-edge technology
InfinityLog was rebuilt on a cutting-edge storage technology designed for exactly this shape of data. Instead of a heavy row per event, similar values are grouped and compressed together, so the same NAT record that cost 150 bytes elsewhere lands in roughly 16 bytes on disk — close to 8–10× smaller. The same 20,000-subscriber network above:
- 70M events/day × 16 bytes ≈ 1.1 GB/day
- Six months of retention ≈ 200 GB — comfortably a single small, fast SSD
A network that a legacy server says needs a 16 TB rack of spinning disks fits on a 2 TB SSD with room to spare. Same logs, same compliance record, same fields at the router — a fraction of the storage.
A quick sizing table
Rough six-month retention, comparing a legacy row-store to InfinityLog's cutting-edge storage:
- 5,000 subscribers — legacy ≈ 470 GB · InfinityLog ≈ 50 GB
- 20,000 subscribers — legacy ≈ 1.9 TB · InfinityLog ≈ 200 GB
- 50,000 subscribers — legacy ≈ 4.7 TB · InfinityLog ≈ 500 GB
- 100,000 subscribers — legacy ≈ 9.5 TB · InfinityLog ≈ 1 TB
These are planning figures — your exact events-per-subscriber and retention policy move them — but the ratio holds: the technology, not the subscriber count, decides whether you're buying gigabytes or terabytes.
Don't forget retention is a dial
BTRC compliance sets a minimum window you must keep; it doesn't force you to hoard forever. InfinityLog lets you set retention per source, so you keep exactly what the rules require and no more. Because each event is so small to begin with, even a generous retention window stays affordable.
The takeaway: before you buy disk to solve a log-storage problem, check whether you actually have a storage-efficiency problem. Most operators are being asked to pay for terabytes because their log server was never built to compress this data. Ours was.