When teams ask why Splunk costs so much, they usually start with the invoice. The more useful question is what the meter is paying for.
Splunk was designed in the 2000s to make heterogeneous machine data searchable without a schema at ingest. That design still works. It also still determines how expensive it is to keep data search-ready as volume grows.
This article is about the architecture: what Splunk optimized for, why the cost of delivering searchable data compounds at high volume, and what we can do at Axiom because settled events are written and read from object storage. If you came for the numbers, the companion piece prices a 1 TB/day workload against publicly available Splunk figures.
Splunk optimized for indexed search
The original problem was real. Machine data arrived as messy, evolving records from many sources. Asking every team to declare a schema before a log could be useful would have killed the product.
Splunk's answer was indexed search. Incoming events are parsed into time-bounded buckets. Those buckets hold compressed raw data plus index files that help a search narrow the work. A small set of fields is recorded at ingest. Many other fields are extracted when the search runs.
That second step is schema-on-read, often described as "search-time field extraction." It's one of Splunk's most durable strengths. Teams can ask new questions of heterogeneous data without fixing every useful field on the way in. An expressive search language, saved searches, dashboards, and detections grew on top of this flexibility, and they still carry real value.
The cost shows up in the third choice. Rich operational use stays tied to the indexed representation and to the indexer resources that search it. Data is "search-ready" when it lives in a form those indexers can hit quickly. The meter, whether it is ingest volume or provisioned workload capacity, prices the full experience rather than a stored gigabyte.
Search-readiness stayed bound to the indexer
Object storage entered the picture later. It didn't change the search path as much as it might first appear.
SmartStore, Splunk's remote-storage model, can make object storage the durable home for warm buckets, which reduces some infrastructure cost. Search still runs through indexers and their local cache. The cache manager has to download an uncached bucket onto an indexer before it can be searched. Object storage here is an archive with a fetch step, not the surface the query engine reads.
Splunk's Machine Data Lake makes the boundary explicit. High-volume data can land in a managed object-storage layer instead of an index, and its Catalog is enough to browse that layer and tell what a dataset holds before anyone commits to it. What the lake cannot do is serve the rich operational experience. When a team needs extracted fields, repeated high-performance search, dashboards, alerts, or correlation, the data has to be promoted into an index. Promotion is the moment the expensive, indexer-bound experience starts.
That is a serious product response to volume. It also confirms the original design: the fully useful operational path still runs through indexed, indexer-local search-readiness. Cheap retention and rich search are two states, with a decision about which data deserves the second one.
Why the cost model blows up at high volume
The cost of goods for indexed search is the capacity required to keep data search-ready, not the cost of keeping bytes around.
Every additional searchable gigabyte needs indexer CPU, index files, and local cache. Every additional day the data stays fully searchable extends the same footprint. Every extra dashboard, concurrent investigation, or busy incident week adds search pressure on the same machines.
Ingest pricing charges for the bytes receiving this treatment. Workload pricing charges for the provisioned capacity that delivers it. The unit on the invoice changes. The underlying resource doesn't.
At tens or hundreds of gigabytes a day, the coupling is tolerable. At terabytes a day it compounds. Adding a source is a budget decision before it is an engineering one. Stretching searchable retention multiplies the same expensive state. Two workloads with identical daily volume can need very different capacity depending on how hard they are searched.
The predictable industry response is to protect the number finance sees. Teams filter sources, sample logs, shorten searchable windows, or leave data in the lake until someone promotes it. We have written before about why sampling to control cost can become a costly mistake: the field or time range dropped today is sometimes the evidence a later investigation needs. At larger scale, ingest itself becomes a data-centre architecture problem rather than a license line.
None of this means the 2000s design was a mistake. It was optimized for a different volume, when keeping every event search-ready on indexers was a reasonable engineering bet. The meter is expensive now because the bet is still inside the product.
Axiom writes and reads from object storage
A common pattern in this category is to treat object storage as the cheap shelf. Data lives there until a query pulls it onto local disks, where the real engine can run. That fetch step is why "we use object storage" and "queries run against object storage" are different claims.
We built Axiom's architecture so settled events are written to object storage and read from it. Recent data is queryable from a live columnar path while blocks are still assembling. Once those blocks settle, they live as compressed, field-aware payloads on object storage and remain in the ordinary query path.
EventDB encodes each field according to its type, density, and cardinality. Real-time compression at ingest, columnar compression inside each block, and background compaction stack to between 25x and 50x, so more than 95% of the physical data is gone. Query workers are ephemeral. They read the columns a question needs, prune blocks that cannot contribute, and expand for a hard investigation without sizing the whole estate for the peak.
That is not an archival trick. There's no customer-triggered restore into a separate search product. Older blocks stay queryable because the query engine was built to operate on them where they already live.
The commercial split follows from this shape. Axiom's pricing bills data loading, query compute, and compressed storage as three usage-based meters. Keeping another month of evidence doesn't require running the largest plausible query footprint for every hour of the month. We rebuilt the pricing around those meters because the architecture can tell them apart.
The first practical step is usually coexistence rather than a cutover. Collectors that already send data through Splunk's HTTP Event Collector (HEC) can send the same traffic to an HEC-compatible endpoint. Teams that write Search Processing Language (SPL) can keep doing so through the Axiom Splunk Portal, which runs the expensive work in Axiom and returns results to the familiar interface. This is what Axiom for Splunk was built for: an architecture that prices retention and query separately is only useful to a Splunk team if they can reach it without leaving the search bar. That is the shape of moving off Splunk without a big bang: one high-volume source moves first while the interface stays put. The broader comparison is useful once the first workload has been measured.
The meter is expensive because of the architecture
Splunk costs what it costs because indexed search, schema-on-read, and indexer-bound search-readiness were the right optimizations for the product it became. At today's volumes, those same choices make searchable data an expensive good to deliver. Axiom can price loading, query, and storage separately because settled events are written and read from object storage, and because query compute can follow the question instead of the retained estate. What that does to a real bill is worked through here, at 1 TB/day.
FAQs
What does "indexer-bound search-readiness" mean?
Data is fully useful for repeated search, dashboards, alerts, and correlation when it is in an indexed state that indexers can hit quickly. Remote object storage can hold warm buckets cheaply, but an uncached bucket still has to be fetched onto an indexer before it can be searched. Search-readiness is a property of the indexer path, not of the bytes existing somewhere.
Why does the cost of goods for Splunk blow up at high volume?
Because volume, searchable retention, and concurrent search all consume the same provisioned resource. More sources, a longer fully searchable window, and a worse incident week all require more indexer capacity or more indexed ingest. The invoice may say gigabytes or workload units. Underneath, the estate is still sized for search-ready data.
How is Splunk's Machine Data Lake different from querying object storage directly?
It gives high-volume data an economical place to land before anyone decides it deserves a full index, and Catalog makes that raw layer discoverable enough to judge what is in it. What it doesn't do is serve the operational path: richer, repeated use still goes through promotion into an index. The lake is the cheap shelf; the expensive search experience starts when data is promoted onto the indexed path.
Does using object storage automatically make a telemetry system cheap?
No. Plenty of systems store data in object storage and still pull it onto local disks to query it. The distinction is whether the query engine operates on the compressed blocks where they live, with enough metadata to avoid reading what the question doesn't need. Storage location without this query path is an archive.
Can a team try this without leaving Splunk's search interface?
Yes. An HEC-compatible ingest endpoint can take one high-volume source while the rest of the estate stays put. Axiom for Splunk covers both routes. The Axiom Splunk Portal answers the provider side of Splunk's federated search protocol, so Axiom datasets resolve like ordinary indexes with nothing installed on the search head. The Axiom for Splunk app reaches the same data through explicit ax commands instead. Either way, existing SPL keeps running and filtering and aggregation execute in Axiom. Coexistence is the usual starting point.
Related reading
See the architecture on your own volume
If the meter on your last renewal felt disconnected from the bytes you store, the useful test is one live source. Book a walkthrough and we will show you how loading, query compute, and storage behave separately when settled events are written and read from object storage.