Searchable snapshots let Elasticsearch query data that lives in a snapshot repository (S3, Azure Blob Storage, GCS, or HDFS) without copying it to local disk in full. They power the cold and frozen data tiers, where storage cost matters more than query latency. A typical use case is keeping the last 7 days of logs in hot/warm tiers on local SSDs and the prior year in a frozen tier backed by S3 - cutting storage cost 5-10x.
When to Use Searchable Snapshots
| Scenario | Suitable? |
|---|---|
| Long-tail log retention beyond hot/warm window | Yes - frozen tier |
| Compliance archive with rare query access | Yes - frozen tier |
| Reducing replicas on infrequently-queried indices | Yes - cold tier (still local, but replicas: 0 safe because snapshot is the durability layer) |
| Primary search workload with low latency requirements | No - searchable snapshots are slower than hot indices |
| Write-heavy indices | No - mounted indices are read-only |
The feature requires a paid Elastic subscription. As of 2026, searchable snapshots are available on the Enterprise tier of self-managed deployments and from Gold and above on Elastic Cloud Hosted. Verify against the current Elastic Subscriptions page before planning.
Cold vs Frozen Tier
| Cold tier | Frozen tier | |
|---|---|---|
| Local disk usage | Full copy on cluster nodes | Cache only - typically 10% of index size |
| Query latency | Near-hot performance | Higher - reads chunks from object store |
| Replicas | 0 (snapshot is durability) |
0 (always) |
| Cost reduction vs hot | 30-50% | 80-90% |
| Typical use | "Recent archive" - last 30-90 days | "Old archive" - months to years |
The frozen tier is the bigger cost lever. It pages chunks from object storage into a local cache on demand, so heavily queried frozen indices warm the cache and behave reasonably; cold-queried data pays object-store latency.
Step-by-Step: Mount a Searchable Snapshot
1. Register a snapshot repository
PUT /_snapshot/cold_storage
{
"type": "s3",
"settings": {
"bucket": "my-elasticsearch-snapshots",
"region": "us-east-1",
"base_path": "cluster-snapshots"
}
}
2. Take a snapshot of the index
PUT /_snapshot/cold_storage/snap-logs-2025-12?wait_for_completion=false
{
"indices": "logs-2025-12-*",
"include_global_state": false
}
3. Mount the snapshot as a searchable index
POST /_snapshot/cold_storage/snap-logs-2025-12/_mount?storage=shared_cache
{
"index": "logs-2025-12-01",
"renamed_index": "logs-2025-12-01-frozen",
"index_settings": {
"index.number_of_replicas": 0
}
}
The storage=shared_cache parameter selects the frozen-tier behavior (chunk cache). Use storage=full_copy for cold-tier behavior (full local copy).
4. Search the mounted index
GET /logs-2025-12-01-frozen/_search
5. Delete the original hot index
Only after verifying the mounted index is queryable - the snapshot is now the source of truth.
Driving Searchable Snapshots from ILM
The realistic deployment is automatic, driven by an Index Lifecycle Management policy:
PUT /_ilm/policy/logs-policy
{
"policy": {
"phases": {
"hot": { "actions": { "rollover": { "max_age": "1d" } } },
"warm": { "min_age": "7d", "actions": { "forcemerge": { "max_num_segments": 1 } } },
"cold": {
"min_age": "30d",
"actions": { "searchable_snapshot": { "snapshot_repository": "cold_storage" } }
},
"frozen": {
"min_age": "90d",
"actions": { "searchable_snapshot": { "snapshot_repository": "cold_storage" } }
},
"delete": { "min_age": "365d", "actions": { "delete": {} } }
}
}
}
The searchable_snapshot action takes the snapshot and mounts the result automatically. The original index is deleted after the mount succeeds.
Performance and Cost Considerations
| Concern | Notes |
|---|---|
| Latency | Frozen tier first-touch can be seconds; subsequent queries hit the cache. Don't put interactive dashboards on frozen |
| Cache sizing | Frozen-tier nodes typically allocate 90%+ of local disk to xpack.searchable.snapshot.shared_cache.size |
| Replicas | Set index.number_of_replicas: 0 on cold/frozen indices - the snapshot is the durability |
| Write back | Mounted indices are strictly read-only. To modify, restore to a regular index, modify, re-snapshot |
| Cross-cluster replication | Not supported with searchable snapshots |
| Forcemerge before snapshot | Always - merging to one segment cuts shard size and improves mounted query performance |
Common Pitfalls
- Mounting indices that weren't force-merged. Many small segments inflate metadata cost and slow queries.
- Sizing the frozen cache too small. Sustained queries against a thrashing cache produce surprisingly poor latency.
- Forgetting the snapshot repository is now part of the production data path. Lose the repository, lose the data.
- Putting interactive workloads on frozen. Expect aggregations across the frozen tier to be 10-100x slower than hot tier.
- Running ILM with
searchable_snapshotaction but no cold/frozen-role nodes. The action fails and the index gets stuck mid-phase.
Run Searchable Snapshot Migrations Safely with Pulse
Pulse is an AI DBA for Elasticsearch and OpenSearch. Before and during searchable snapshot operations driven by ILM searchable_snapshot actions or manual _mount calls, Pulse:
- Verifies cluster capacity for the operation: frozen-tier nodes are configured and reachable,
xpack.searchable.snapshot.shared_cache.sizeis sized for the index, snapshot repository (S3/GCS/Azure) is healthy - Surfaces concurrent operations that could collide - active snapshots, restores, or ILM phase transitions sharing the repository
- Tracks the operation's progress and impact in real time: frozen-tier cache hit rate, ILM phase progress, stuck
searchable_snapshotactions, query latency on the mounted indices - Recommends throttling restore or pausing the ILM phase if production search latency starts climbing, and points at the bottleneck (cache, object store, or index layout) when a frozen query is unexpectedly slow
Start a free trial before your next cold/frozen tier migration.
Frequently Asked Questions
Q: What are searchable snapshots in Elasticsearch?
A: Searchable snapshots are snapshots stored in object storage (S3, Azure Blob, GCS) that Elasticsearch can query directly without copying to local disk in full. They power the cold and frozen data tiers and reduce storage cost 5-10x versus keeping indices in hot tier.
Q: What's the difference between the cold and frozen tier?
A: Cold tier keeps a full local copy of the index with replicas: 0 and snapshot as durability - near-hot performance, ~30-50% cost reduction. Frozen tier keeps only a local chunk cache and reads from object storage on demand - higher latency, 80-90% cost reduction.
Q: Can I write to a searchable snapshot index?
A: No. Mounted indices are strictly read-only. To modify the data, restore the snapshot to a regular index, make the changes, then re-snapshot and re-mount.
Q: What Elasticsearch license do searchable snapshots require?
A: A paid Elastic subscription. As of 2026, self-managed deployments require Enterprise; Elastic Cloud Hosted unlocks searchable snapshots from Gold and above. Check the current Elastic Subscriptions page for your version.
Q: How do I migrate an existing index to a searchable snapshot?
A: Force-merge to one segment, take a snapshot, mount the snapshot with _mount?storage=shared_cache (frozen) or storage=full_copy (cold), verify the mounted index is queryable, then delete the original. ILM automates this with the searchable_snapshot phase action.
Q: Are searchable snapshots compatible with cross-cluster replication?
A: No. Cross-cluster replication isn't supported on mounted indices. To replicate cold/frozen data across clusters, share the underlying snapshot repository instead.
Q: What's the best tool to safely roll out searchable snapshots and frozen tier in production?
A: Pulse is purpose-built for this. It is an AI DBA for Elasticsearch and OpenSearch that pre-checks frozen-tier cache sizing, repository health, and concurrent ILM phases, tracks cache hit rate and mounted-index query latency, and recommends targeted fixes when a frozen query slows down - whether the bottleneck is cache size, object store throughput, or index layout.
Related Reading
- Elastic Cloud Pricing Guide: Cost impact of tier choice
- Elasticsearch Scaling Nodes Hot Warm Architecture: Tiered architecture
- Elasticsearch indices.recovery.max_bytes_per_sec Setting: Recovery and snapshot throughput
- Amazon OpenSearch Service Manual Snapshots: Snapshot management on AWS
- Elasticsearch Index Lifecycle Name: ILM basics
