When platform teams ask what it costs to store a gigabyte of machine data in Splunk, they are usually trying to turn a rising bill into one comparable number. Splunk doesn't sell a flat storage rate. It sells ingest volume, or provisioned workload capacity, combined with a retention path that changes the price depending on how long that data stays searchable.
That combination is why two teams running the same daily volume can land on very different annual bills. One keeps a short searchable window and restores older data on demand. Another pays to keep more of it live and query-ready.
This article consolidates the publicly available pricing data. A companion piece covers the architecture underneath the meter: what Splunk optimized for, and why delivering searchable data gets expensive at volume.
Splunk's price is set by ingest volume and the retention path chosen
Splunk Cloud licenses a workload two ways: by ingest volume per day, or by provisioning Splunk Virtual Compute (SVC) capacity sized to the indexing and search load. Neither number describes a stored gigabyte on its own. Retention adds a second dimension.
Data can sit in an indexed, fully searchable state, or move into a separately priced archive that has to be restored before it's searchable again. In Splunk's newer model, data can also land first in a raw, non-indexed tier and get promoted into an index later, when a question demands richer search. Each state returns a different amount of usable data for a different price, which is why the reflex question (what does a gigabyte cost) rarely has one answer.
Where the $822.25 per gigabyte figure comes from
Splunk doesn't publish its core commercial rates on its public website. Publicly available documents for government procurement list Splunk Cloud's ingest-priced tier at $822.25 per GB/day, per year, at the 1,000–1,999 GB/day band. Older US and state government schedules show the same per-gigabyte structure at smaller tiers, which is why we treat this figure as representative rather than a one-off quote.
Extending the same workload's retention across a full year costs roughly 45% more
At 1 TB/day per day, the $822.25 rate alone works out to about $822,250 a year for the base subscription's included searchable window. The same publicly available documents price additional archived retention separately, in increments per 500 gigabytes, and archived data has to be restored before it's searchable again. Carrying that same workload across a full year of retention, rather than stopping at the subscription's included window, raises the annual total to roughly $1.195 million, about 45% more for the same data held longer. The gap shows that "storage" and "searchable" are two different purchases in Splunk's model.
Splunk is building its own cheaper raw-storage tier
Splunk's own product direction backs this up. In August of 2026, Splunk made its Machine Data Lake and Catalog generally available in supported Splunk Cloud environments: a managed, object-storage layer where high-volume data can land and be retained economically without indexing every event immediately. Catalog is the discovery layer over it: teams can narrow by source, sourcetype, host, and time range, and inspect a dataset's event volume, time coverage, and field schema before committing to it.
When a team needs richer, repeated search, dashboards, alerts, or correlation, Splunk's own guidance describes promoting selected data out of the lake and into an index or analytics table, which carries its own separate cost. Splunk hasn't published complete public rates for raw landing, raw search, and promotion, so that path is worth a direct quote rather than an estimate. Its existence is still a useful signal: Splunk is responding to the same pressure behind every ingest bill, by building a cheaper tier for data that doesn't need full indexing all the time.
Rising bills push teams toward filtering, sampling, and shorter retention
Under either commercial model, a rising bill tends to produce the same industry-wide response. Under ingest pricing, adding a new data source is a budget decision before it's an engineering one. Under workload pricing, more indexing and search pressure means provisioning more SVC capacity.
Teams commonly respond by filtering sources, sampling logs, shortening searchable retention, or routing lower-priority data elsewhere to protect the number finance sees. That isn't a mistake specific to one company; it's a predictable response to a cost model that ties price directly to volume and search readiness. The trade-off is that the field or time range dropped today is sometimes exactly the evidence a future incident needs. We have written before about why sampling logs to control cost can turn into a costly mistake.
Axiom separates loading, query, and storage into three usage-based meters
We built Axiom's pricing around a different split. There's one paid plan called Axiom Cloud, and it includes an Always Free allowance each month of 1 TB of data loading, 100 GB-hrs of query compute, and 100 GB of storage.
Both query compute and storage scale with actual use rather than a provisioned capacity tier. Automatic volume discounts apply as usage grows, and a credit pre-purchase lowers the rate further for teams that can commit ahead of time. Our reimagined pricing approach and the way ingest becomes a data-centre architecture problem at petabyte scale both walk through why we split the meters this way.
Modeling that same 1 TB/day workload on our public pricing mechanics (a realistic query-compute profile, Axiom's compression, tiered storage, and a 12-month credit pre-purchase) lands at roughly $56,600 a year for the shorter retention window and roughly $57,600 a year across a full year of retention. That's an illustrative estimate built from our published pricing mechanics, not an official list price; any real workload should be modeled against axiom.co/pricing rather than this figure. The pattern worth noticing is how little the retention window moves the Axiom number compared with how much it moves Splunk's. The architecture that makes this possible, writing and reading settled events from object storage, is the companion article.
Keeping the Splunk interface while the data moves
A first move doesn't have to be a migration, and it doesn't have to wait for a renewal date. One high-volume, high-cost source can be redirected to an HEC-compatible ingest endpoint, which the collectors already pointed at Splunk can reach with a change of destination and nothing else. Axiom for Splunk then puts that source back in front of the people who query it: the Axiom Splunk Portal makes it appear in the index list, and the Axiom for Splunk app adds ax commands to the search bar. Both run at search time, so neither consumes Splunk ingest license. That is what makes the experiment cheap enough to run before a renewal rather than after one, and it is the practical alternative to a big-bang migration. The broader comparison and integration details help size a wider move once that first bill has been measured.
The real cost question is the ingest meter plus the retention path, and it can be tested before it's signed
Splunk's bill is set by ingest volume or workload capacity, multiplied by whichever retention path a team chooses. That combination, not a stored-gigabyte price, is what belongs in any comparison run against a real workload before a renewal is signed.
FAQs
Does Splunk charge a flat rate per gigabyte of stored data?
No. Splunk Cloud licenses a workload by ingest volume per day or by provisioned Splunk Virtual Compute (SVC) capacity, and then charges separately for the retention path chosen. A gigabyte held in the base subscription's searchable window and the same gigabyte moved into archived retention are two different line items on the same bill, which is why a single "storage rate" doesn't exist in Splunk's published pricing.
Where does the $822.25 per GB/day, per year, figure come from, and is it official?
It comes from publicly available documents used in government procurement, not a rate Splunk publishes on its public website. Those documents list the ingest-priced tier at $822.25 per GB/day, per year, at the 1,000–1,999 GB/day band. Older US and state government schedules show the same per-gigabyte structure at smaller tiers, which is why we treat this figure as representative rather than a one-off number.
How much more does it cost to keep Splunk data searchable for a full year instead of the default window?
On the same publicly available documents, extending a 1 TB/day workload's searchable retention across a full year raises the annual total from roughly $822,250 to roughly $1.195 million, about 45% more for the same data held longer. That increase comes from archived retention being priced separately, in increments per 500 gigabytes, on top of the base ingest subscription.
What is Splunk's Machine Data Lake, and does it change the cost picture?
It's a managed, object-storage layer Splunk made generally available in supported Splunk Cloud environments in 2026, where high-volume data can land and be retained without indexing every event immediately. Teams can browse it with a Catalog feature and run narrow raw search directly against it, but promoting data into a full index or analytics table for repeated search, dashboards, or alerts carries its own separate cost. Splunk hasn't published complete public rates for landing, searching, and promoting data in this tier, so it's worth a direct quote rather than an estimate.
How is Axiom's pricing structured differently from Splunk's?
Axiom's pricing separates data loading, query compute, and compressed storage into three usage-based meters instead of one ingest number that also covers search and retention. The Axiom Cloud plan includes a monthly Always Free allowance across all three meters, and usage above that is billed at the standard rate. Both query compute and storage scale with actual use rather than a provisioned capacity tier. Volume discounts apply automatically as usage grows, and a credit pre-purchase lowers the rate further for teams that can commit ahead of time.
How does a 1 TB/day workload compare between Splunk and Axiom in dollar terms?
On the publicly available Splunk Cloud figures we reviewed, that workload runs roughly $822,250 a year at the base searchable window and roughly $1.195 million across a full year of retention. Modeling the same workload on Axiom's public pricing mechanics lands at roughly $56,600 a year for the shorter window and roughly $57,600 a year across a full year of retention. Both Axiom figures are illustrative estimates built from published pricing mechanics, not official quotes, and any real workload should be modeled against axiom.co/pricing.
Can a team move data to Axiom without giving up Splunk's search interface right away?
Yes, and the interface is the part that doesn't change. Redirecting one source to an HEC-compatible ingest endpoint is a destination change in the collector, not a re-instrumentation. Axiom for Splunk then covers both ways of reaching that data from inside Splunk, either as an entry in the index list or through ax commands in the search bar, and both operate at search time without consuming Splunk ingest license. The practical effect is that a team can price one source on Axiom while the rest of the estate carries on untouched.
What's a lower-risk first step than a full Splunk-to-Axiom migration?
Filtering sources, sampling logs, or shortening searchable retention are the common near-term levers teams pull to control a rising Splunk bill, though each one trades away data that a future incident might need. A lower-risk first step that doesn't require dropping data is routing one high-volume, high-cost source to Axiom through the HEC-compatible endpoint while keeping the rest of the Splunk estate in place, then measuring the result before deciding how much further to move. The Axiom and Splunk comparison and integration overview are useful starting points for sizing that first move.
Related Reading
Model your own ingest and retention numbers
The figures above come from publicly available documents at one volume; your own ingest rate, retention window, and data mix will move the real number. Book a walkthrough and bring a representative source so we can show what loading, query, and storage cost separately against your actual volume, rather than an estimate built from someone else's price list.