Splunk Storage Sizing

The average daily volume Splunk will ingest. Everything below scales from this number.

Splunk doesn't publish a fixed growth figure — its guidance is simply to re-forecast capacity regularly. A common rule of thumb is 20–40% headroom on top of today's need.

Where the index buckets actually live.

Classic layout — hot/warm buckets on the fastest local disk, cold on slower/cheaper disk, archived (frozen) on the cheapest. Cluster replication multiplies every stored copy.

Buckets upload once to S3-compatible object storage; each indexer keeps a local SSD cache of the working set. The remote store holds a single copy of every bucket regardless of replication factor.

Data rolls through each tier as it ages. Archived (frozen) data is no longer searchable — set it to 0 to skip archiving.

All searchable data lives in the remote store until it freezes. The cache working set is how much recent data each indexer keeps locally on SSD.

Splunk recommends provisioning cache for ≈30 days of indexed data — or 90 days for Enterprise Security.

Pick a use case for a per-indexer volume guideline, or set your own.

These GB/day figures are starting points, not hard limits — validate against your own data mix and search load. Splunk's guidance for Enterprise Security runs roughly 60–100 GB/day per indexer (100 is the high end); a generic indexer on reference hardware handles up to ~300 GB/day.

With SmartStore, replication factor affects only hot buckets and cache metadata — the remote store keeps one copy per bucket, so it doesn't change these figures. The cluster setting still matters for the config, which needs repFactor = auto on peer nodes.

Breakdown of the overall requirement.

Set the price per GB for each kind of storage.

Object storage is normally billed per GB-month while local disk is one-off capex — enter whichever basis you want these totals to reflect.

Storage prices are estimates only. These totals exclude servers and compute, Splunk licensing, support, networking, and object-storage request/retrieval charges — they are not a total cost of ownership.

Turns storage required into disk to actually buy — disks shouldn't run full, and RAID/filesystem overhead eats raw capacity.

Generated for a single index. Adjust paths and bucket names, then deploy. On a cluster, push from the manager node — never edit peers directly.

Every assumption behind the figures above, with its current value.