Splunk SmartStore sizing
SmartStore separates how long you keep data from how much local disk you need. This guide shows how to size the cache, the object store and the hot-bucket replicas, and when the trade-off pays off.
In short
- Local disk ≈
cache days × indexed/day+ replicated hot buckets, then growth. Retention does not appear. - Object store ≈
indexed/day × (retention − hot window), one copy, then growth. - In the illustrative example below (250 GB/day, RF2/SF2, 30-day cache), local disk is 4.84 TB whether you keep 90 days or a year; only the object store grows (13.9 TB vs 56.9 TB).
Where data lives
| State | Location | Copies | Sizing driver |
|---|---|---|---|
| Hot | Indexer local disk | RF rawdata copies, SF searchable copies | Daily ingest × hot window |
| Warm (master copy) | Remote object store | One copy, uploaded when the bucket rolls from hot | Indexed/day × (retention − hot window) |
| Warm (cached) | Indexer local cache | Copies fetched on demand and evicted when space is needed | Cache days you choose |
The cache manager evicts least-recently-used buckets when the cache fills, so the cache is a working set, not an archive. A search over buckets that are not cached downloads them from the remote store first.
Cache is not retention
Splunk's SmartStore requirements recommend local storage for about 30 days of indexed data, at least 7–10 days because most searches target recent data, and about 90 days with Enterprise Security.
Reference scenario 1 TB/day, RF3/SF2, kept 365 days:
| Cache window | Local cache | Local storage with hot replicas and growth | Link |
|---|---|---|---|
| 7 days (minimum) | 3.5 TB | 5.19 TB | Open this scenario in Splunk |
| 30 days (default) | 15 TB | 19.6 TB | Open this scenario in Splunk |
| 90 days (Enterprise Security) | 45 TB | 57.1 TB | Open this scenario in Splunk |
| 365 days (= retention) | 182.5 TB | 228.9 TB | Open this scenario in Splunk |
A cache sized to retention gives up the main benefit of SmartStore: local disk ends up close to a single full copy of every bucket. Size the cache from the search window your users and scheduled searches actually use. Splunk also notes that the cache shares its partition with the operating system, binaries and search artifacts, which must fit as well.
Worked example: 250 GB/day, RF2/SF2, 90 days
Illustrative example inputs chosen to compare with the classic medium scenario.
| Step | Formula | Result |
|---|---|---|
| Indexed size per day | 250 GB × (0.15 + 0.35) | 125 GB/day |
| Local cache | indexed/day × 30 days | 3.75 TB |
| Hot-bucket replicas | 250 GB × 1 day × (0.15 × (RF−1) + 0.35 × (SF−1)) | 125 GB |
| Local storage with 25% growth | (cache + hot replicas) × 1.25 | 4.84 TB |
| Object store | indexed/day × (90 − 1) days | 11.1 TB |
| Object store with 25% growth | × 1.25 | 13.9 TB |
The same data on classic storage needs 28.1 TB of indexer disk. Open this scenario in Splunk · Open the classic version.
Classic vs SmartStore
Illustrative example the same 250 GB/day at two retentions.
| Retention | Classic indexer storage | SmartStore local | SmartStore object store |
|---|---|---|---|
| 90 days | 28.1 TB | 4.84 TB | 13.9 TB |
| 365 days | 114.1 TB | 4.84 TB | 56.9 TB |
Classic storage grows with retention on fast, replicated disk. SmartStore keeps local disk flat and grows a single remote copy. The longer the retention relative to the search window, the larger the gap.
Enterprise Security caveat
Splunk's requirements call for about 90 days of indexed data in cache with Enterprise Security, whose correlation searches and accelerated data models commonly read further back than ad hoc searches. For 1 TB/day at RF3/SF2 that is 57.1 TB of local storage instead of 19.6 TB. If ES runs on the cluster, start the cache at 90 days and reduce it only with evidence from cache-hit behavior.
When SmartStore makes sense
- Long retention, short search window. A year kept, 30 days searched: local disk stays at the cache size.
- Object storage with adequate throughput close to the indexers, since cache misses download whole buckets.
- Elastic indexer counts. Adding or replacing peers does not require copying all retained data between them.
It fits less well when searches routinely span the full retention (most searches become downloads), when retention is already short (the cache would equal retention), or when no suitable object store is available. In Splunk Cloud Platform SmartStore is managed by Splunk, so this sizing applies to Splunk Enterprise.
Common mistakes
- Cache = retention. 228.9 TB of local disk instead of 19.6 TB for the 1 TB/day example — 11.7× more.
- Ignoring hot-bucket replicas. Hot buckets follow RF and SF locally: 650 GB per day of hot window at 1 TB/day RF3/SF2.
- Replicating the object store in the estimate. Warm buckets exist once in the remote store; applying RF to it triples the object store for RF3.
- Using the ES-free 30-day default with Enterprise Security. Searches that miss the cache download buckets and slow correlation searches.
- Forgetting non-bucket data on the cache partition. OS, Splunk binaries and search artifacts share it.
Limitations
- One hot window for the whole cluster; real hot bucket lifetime depends on bucket size and roll settings.
- Per-index cache settings, eviction policies and bucket sizes are not modeled.
- Object store request costs, egress and replication inside the object store are outside the estimate.
- Multisite clusters and Splunk Cloud entitlements are not modeled.
Sources
- SmartStore architecture overview — Splunk Enterprise documentation, 10.2.
- SmartStore system requirements — Splunk documentation, 10.2: 30 days, 7–10 days minimum, 90 days with Enterprise Security, shared cache partition.
- System requirements and other deployment considerations for indexer clusters — Splunk Enterprise documentation, 10.6: rawdata and index-file ratios.
- Buckets and indexer clusters — Splunk Enterprise documentation, 10.2.
Last reviewed: · Splunk Sizing & Storage Calculator · Capacity Planning · Methodology