Splunk Sizing Calculator
Storage, indexers and retention for Splunk Enterprise, with transparent RF/SF assumptions.
Show math
Replication Factor vs Search Factor
Replication Factor (RF) is how many copies of each bucket the cluster keeps. Every copy holds the compressed rawdata. Search Factor (SF) is how many of those copies are searchable; only searchable copies also hold the index (TSIDX) files. That is why rawdata scales with RF and TSIDX with SF, and why SF can never exceed RF.
Assumptions & sources
- Rawdata ≈15% × RF and index files ≈35% × SF of pre-indexed volume. Splunk documents these as a ballpark for syslog data (100 GB with RF 3 / SF 2 → 45 GB rawdata + 70 GB index files = 115 GB) and notes that the estimate can vary substantially by data source. Source: Splunk Enterprise docs — System requirements and other deployment considerations for indexer clusters (Storage requirement examples). Background: Splunk blog — Disk space estimator for index replication.
- Non-searchable copies hold rawdata only; searchable copies also hold index files. Source: Splunk docs — Buckets and indexer clusters.
- SmartStore keeps RF/SF copies of hot buckets locally; buckets are uploaded to the remote store only when they roll to warm, where they exist once with only their metadata replicated. ObservKit therefore sizes the object store as indexed data × (retention − hot window), using the hot window as a planning assumption. Source: Splunk docs — SmartStore architecture overview.
- SmartStore cache: Splunk generally recommends local storage for ~30 days of indexed data, a minimum of 7–10 days, and ~90 days with Enterprise Security. ObservKit defaults to 30 days; set it to your real search window. Source: Splunk docs — SmartStore system requirements.
- Not modeled: hot/warm vs cold volume split, multisite clusters, data model acceleration and summary indexes, OS/filesystem overhead, Splunk Cloud licensing.
Planning estimates only. Actual Splunk architecture depends on workload, search concurrency, data model acceleration, hardware/cloud profile and Splunk architecture guidance.
Worked example: Splunk RF3 / SF2
Illustrative example An indexer cluster receiving 200 GB/day of pre-indexed data, keeping it 90 days, with Replication Factor 3, Search Factor 2 and a 25% growth buffer. Classic (non-SmartStore) storage, default ratios. Open this scenario.
| Step | Formula | Result |
|---|---|---|
| Pre-indexed volume P | 200 GB/day × 90 days | 18 TB |
| Rawdata, one copy | P × 0.15 | 2.7 TB |
| Rawdata on every copy | P × 0.15 × RF 3 | 8.1 TB |
| Index (TSIDX) files, one copy | P × 0.35 | 6.3 TB |
| Index files on searchable copies | P × 0.35 × SF 2 | 12.6 TB |
| Cluster indexed storage | rawdata + index files = 1.15× P | 20.7 TB |
| Growth buffer | × 25% | 5.18 TB |
| Recommended indexer storage | cluster + growth | 25.9 TB |
Why 0.5 × RF is wrong when RF ≠ SF
The shortcut P × 0.5 × RF assumes every bucket copy carries both rawdata and index files. In an indexer cluster only searchable copies carry index files, so the shortcut silently assumes SF = RF. For this scenario it produces 33.8 TB — exactly the RF3/SF3 answer — instead of 25.9 TB: 30% more disk than RF3/SF2 actually needs. The two formulas only agree when SF equals RF.
Check against Splunk's documented example
Splunk's indexer-cluster requirements use 100 GB of syslog data with RF 3 and SF 2: about 15% rawdata × 3 copies plus about 35% index files × 2 searchable copies. The engine reproduces it with no growth buffer: 45 GB rawdata + 70 GB index files = 115 GB. Open this scenario.
The indexer estimate for the worked example is 3 peers: it never goes below RF, because RF 3 needs three peers to place three copies of every bucket.
Reference scenarios
Reference scenario Each row is computed by the same engine as the calculator above and opens with its inputs filled in; these are reference points to compare against, not recommended sizes. All use the default 15% rawdata and 35% index-file ratios and a 25% growth buffer.
| Scenario | Inputs | Local indexer storage | Object store | Indexers (est.) | Link |
|---|---|---|---|---|---|
| Small | 50 GB/day · 30 days · RF2/SF2 | 1.88 TB | — | 2 | Open this scenario |
| Medium | 250 GB/day · 90 days · RF2/SF2 | 28.1 TB | — | 2 | Open this scenario |
| Large, classic | 1 TB/day · 365 days · RF3/SF2 | 524.7 TB | — | 4 | Open this scenario |
| Large, SmartStore | 1 TB/day · 365 days · RF3/SF2 · 30-day cache · 1-day hot window | 19.6 TB | 227.5 TB | 4 | Open this scenario |
The two large rows hold the same data. Classic storage keeps a year of rawdata on three copies and index files on two: 524.7 TB of local disk. SmartStore keeps one copy of warm buckets in the object store (227.5 TB with growth) and only the cache plus replicated hot buckets locally (19.6 TB). SmartStore does not make the data smaller; it moves the long tail from replicated local disk to a single remote copy.
Sizing decisions
RF vs SF
Replication Factor is availability of data: with RF 3 the cluster keeps three copies of every bucket and can lose two peers without losing data. Search Factor is availability of search: only searchable copies carry index files, so SF decides how many peers can fail before some buckets must have index files rebuilt from rawdata before they are searchable again.
The storage cost of each is different. In the worked example one extra RF copy adds 2.7 TB of rawdata (P × 0.15); one extra SF copy adds 6.3 TB of index files (P × 0.35), both before growth. Index files are the larger part, which is why SF moves the total more than RF.
SF lower than RF
Going from RF3/SF3 to RF3/SF2 in the worked example lowers recommended storage from 33.8 TB to 25.9 TB, a saving of 7.88 TB. The cost is recovery: when a searchable copy is lost, the cluster has to build index files on a remaining non-searchable copy, which takes time and indexer CPU/IO while search results for those buckets are incomplete. SF = RF is the choice when recovery time matters more than disk; SF < RF when disk dominates and slower search recovery is acceptable. Neither is universally better.
SmartStore
With SmartStore, hot buckets stay local and follow RF/SF. When a bucket rolls to warm it is uploaded once to the remote object store; peers keep a local cache of recently used buckets and fetch the rest on demand. Sizing changes in three ways: local disk follows the cache window instead of retention, the object store follows retention minus the hot window with one copy, and the hot window still needs RF/SF copies locally. The SmartStore sizing guide works through cache sizing in detail.
Common mistakes
- Using
0.5 × RFfor every cluster. It equals the RF = SF answer. At RF3/SF2 in the worked example it overestimates storage by 30% (33.8 TB instead of 25.9 TB). - Sizing the SmartStore cache to full retention. Illustrative example For 1 TB/day kept 365 days at RF3/SF2, a 365-day cache asks for 228.9 TB of local disk; a 30-day cache needs 19.6 TB — 11.7× less. Splunk's SmartStore requirements suggest about 30 days of indexed data, at least 7–10 days, and about 90 days with Enterprise Security (57.1 TB here). Open the 365-day cache scenario.
- Forgetting hot-bucket replication under SmartStore. Hot buckets are not in the object store yet, so they keep RF rawdata and SF index-file copies locally. In the 1 TB/day RF3/SF2 reference scenario a one-day hot window adds 650 GB of replica copies on top of the cache, before growth. Longer hot windows scale it linearly.
- Confusing licensed volume with real ingest. A license is an entitlement, not a measurement. Hypothetical example Sizing a 90-day RF2/SF2 cluster from a 500 GB/day license when the measured volume is 320 GB/day gives 56.3 TB instead of 36 TB — 56% too much. Use measured daily license usage, and look at peak days as well as the average.
- Assuming one compression factor for every source. Splunk presents 15% / 35% as a syslog ballpark that varies by source. Hypothetical example The worked example becomes 18 TB if a source compresses to 10% rawdata and 25% index files, and 32.6 TB if index files reach 50%. Measure your own ratio per index (for example, compare on-disk bucket size from
| dbinspectwith raw size) and enter it in Expert mode.
How Splunk sizing is calculated
All volumes use decimal units (1,000 GB = 1 TB). P is the pre-indexed volume kept for the retention period.
Classic indexer storage
P = daily ingest × retention days
rawdata = P × rawdata ratio (0.15) × RF
index = P × index-file ratio (0.35) × SF
recommended = (rawdata + index) × (1 + growth)SmartStore
indexed/day = daily ingest × (0.15 + 0.35)
local cache = indexed/day × cache days (default 30)
hot replicas = daily ingest × hot days × (0.15 × (RF − 1) + 0.35 × (SF − 1))
local = (cache + hot replicas) × (1 + growth)
object store = indexed/day × (retention − hot days) × (1 + growth) one copyAssumptions and limits
- The 15% / 35% ratios are Splunk's documented syslog ballpark; both are editable in Expert mode.
- Growth is applied after copies, so headroom scales with the footprint you actually provision.
- The indexer count is an ObservKit planning heuristic (about 300 GB/day per reference indexer, never fewer peers than RF), not Splunk sizing guidance. Search concurrency, data model acceleration and premium apps are not modeled.
- Not modeled: hot/warm vs cold volume split, multisite clusters, summary indexes and accelerated data models, OS and filesystem overhead, Splunk Cloud entitlements.
The common capacity model behind all ObservKit calculators is described in the methodology.
Sources
- System requirements and other deployment considerations for indexer clusters — Splunk Enterprise documentation, 10.6. Storage requirement examples: 15% rawdata, 35% index files, the RF3/SF2 100 GB example.
- Buckets and indexer clusters — Splunk Enterprise documentation, 10.2. Searchable vs non-searchable bucket copies.
- SmartStore architecture overview — Splunk Enterprise documentation, 10.2. Hot buckets local, warm buckets in the remote store, local cache.
- SmartStore system requirements — Splunk documentation, 10.2. Cache sizing: about 30 days, at least 7–10 days, about 90 days with Enterprise Security.
- Disk space estimator for index replication — Splunk blog. Background only.
Last reviewed: · Related: Splunk SmartStore sizing guide · Capacity Planning · generic log storage calculator