Loki vs OpenSearch storage cost: where the money goes
Loki spends less on indexing because it indexes only labels for each log stream, while OpenSearch builds a full-text Lucene index over the contents of every document and splits each index into shards. For a regulated team sending logs from many systems and keeping them for a fixed retention period, that difference moves the bill in different places. Loki keeps compressed chunks in object storage such as Amazon S3, so most of the recurring cost is object storage capacity, request traffic and the small compute footprint of the ingest, query and compactor components. OpenSearch keeps searchable index data on nodes with local storage, so its recurring cost tracks disk, memory for the shard and index overhead, and the number of nodes needed to hold the retention window with replicas. Neither product has a paid edition in the supplied facts, so the comparison is between infrastructure you size and operate yourselves, not between license fees. The answer depends on three inputs: how often you query, what you query for, and how long you keep data. Loki gets cheaper per stored gigabyte as long as your queries filter on labels such as application, environment or tenant and then scan chunks. Free-text searches across high-volume streams with no selective labels force Loki to read far more data, which raises query compute and egress costs. OpenSearch handles those ad hoc full-text and security analytics queries better, but it pays for that capability in index storage and heap. Retention is the multiplier in both cases. Loki retention is off by default, so the team must enable it on purpose, with the compactor applying global, per tenant or per stream rules of at least 24 hours each. Confirm your required retention period, your daily ingest volume and your label design before you ask any vendor or partner for a sizing estimate.
Storage cost components, Loki against OpenSearch
This table breaks log storage spend into its component parts and shows how Loki and OpenSearch each generate those costs. Read each row as a question to put to your own volumes and retention targets, since neither platform's public facts supply a price. The main takeaway is that Loki's cost sits mostly in object storage and retention settings, while OpenSearch's cost sits mostly in index size, shard layout and the nodes that hold them.
| Cost component | Loki (label index, object storage) | OpenSearch (inverted index, shards) |
|---|---|---|
| Index size | Index covers only labels for each log stream, not log contents, so index growth tracks stream count and label cardinality. | Inverted index builds terms for full text across fields, so index size grows with the content you index and the fields you map. |
| Raw data storage | Compressed log chunks sit in object storage such as S3, which is the main recurring storage line. | Documents and index structures sit on node disks, so raw data plus index is typically held on block or local storage. |
| Replication and durability | Durability comes from the object store's own design; confirm the replication and region terms with your provider or self-managed store. | Replica shards multiply stored data; the replica count you set is a direct storage multiplier to confirm in your cluster design. |
| Compute for ingest and query | Distributor, ingester and querier components scale with write rate and query load; the deployment mode you choose sets how these are split. | Data nodes handle indexing and search together, so ingest and query load compete for the same CPU, heap and disk I/O. |
| Shard management | No shard layer; the index is organized by labels and time rather than by shard count. | Each shard is a full Lucene index with its own overhead, so shard count and size directly affect heap use and cluster sizing. |
| Hot and warm storage tiers | Storage tiering is handled by the object store's lifecycle options rather than a Loki setting; confirm what your store supports. | Hot and warm tiers are an operator choice, so you pay for the storage class and node type you assign to each tier. |
| Retention enforcement | The compactor applies retention, but retention is disabled by default, so logs are kept indefinitely until you set it. | Retention is handled by index lifecycle policies that you define and maintain; confirm how your version and plugins enforce them. |
| Licensing | AGPLv3 with no paid edition needed to run the open-source build; consider the AGPL obligations if you modify and serve it. | Apache-2.0 with no paid edition described in its FAQ; the cost is the infrastructure and operating effort, not a license fee. |
| Quote questions to ask | Ask the integrator to model stream count, label cardinality, daily volume, object store pricing and the retention period per tenant. | Ask for the expected index size per day, shard count, replica count, tier layout and the retention and lifecycle policy in the scope. |
Which factors move log storage cost the most
Log storage cost is set by how much data you keep, how it is indexed and where it sits. Loki and OpenSearch respond to these drivers in different ways, so the same daily volume can produce very different bills. The cards below cover the levers to model before you compare quotes or hardware.
Label cardinality and stream count
In Loki, every unique combination of labels creates a stream, and each stream adds index entries and small chunks that must be written and compacted. High-cardinality labels such as request IDs or user IDs multiply stream count and can raise both index and object request costs quickly. Check which labels your shippers attach by default and whether any value is unbounded before you size the store.
Field count and full-text indexing
OpenSearch builds an inverted index over the text of every document it ingests, and each shard is a full Lucene index. More indexed fields and more free text per event increase index size, heap pressure and disk use, whether or not anyone queries those fields. Ask which fields are mapped as indexed, which can be stored without indexing, and how much of each event is searchable text.
Daily ingest volume
Daily volume sets the baseline for both platforms. Loki's documented deployment modes are sized by daily log volume, and the mode you choose changes how many components you run and what they cost to operate. For OpenSearch, daily volume drives shard count, node count and disk. Measure real bytes per day from your sources, including verbose debug output, rather than estimating from headcount or host count.
Retention period and retention rules
Retention usually moves cost more than any other lever because it multiplies everything stored. Loki retention is disabled by default, so logs are kept indefinitely until you set retention_enabled and define rules globally, per tenant or per stream selector, with each stream rule at least 24 hours. A default that never deletes can quietly grow an object store bill, so set the rules before go-live and confirm them against your audit and incident response needs.
Query frequency and search scope
Loki reads only the chunks that match label selectors and the time range, so frequent narrow queries stay affordable on object storage. Broad full-text searches across many streams force Loki to scan more chunks, which adds compute and object read cost. OpenSearch answers term searches from its index, so heavy investigative search can keep cluster resources busy around the clock. Write down your top ten queries, their time ranges and how often analysts run them.
Object store choice and hosting
Loki keeps compressed chunks and its index in object storage. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production options, while MinIO and the local filesystem are supported but not typically recommended for production. Your storage price, request charges, egress, and the team that runs a self-hosted S3-compatible store all become line items. Confirm the object store you will use and who owns its availability and backups.
What you give up in query power to lower storage spend
Loki's label-first design makes queries that filter by labels such as namespace, app or cluster efficient, because the index only points to the streams and time ranges that matter. Once a query searches for a string that no label captures, such as a user ID buried in a message body or an indicator of compromise in a payload, Loki has to read and decompress the relevant compressed chunks and scan them. That is cheap when the time window is narrow and the streams are well labeled, and expensive when analysts run broad free-text hunts across weeks of data. The saving on storage is paid for in query time and in the discipline of label design. Ask your analysts to list their ten most frequent searches and mark which ones filter on a label and which ones search message content.
OpenSearch builds an inverted index for full-text search, and each shard is a full Lucene index, so term lookups, phrase searches and aggregations across message fields stay fast. That capability is the reason security analytics teams choose it, and it is also what drives the larger index footprint and shard management that appear in your storage bill. Security features add their own cost. The OpenSearch Security plugin provides role-based access control, document-level and field-level security, field masking, user impersonation and audit logs. If analysts in different teams must see different fields or documents, or if audit trails are required, those controls are configured and tested as part of the design, and they add operating effort. Confirm whether you need these controls in the first release, because a log store that only the platform team can query has a different cost profile from one shared across tenants.
Before you commit to either platform, confirm the query patterns your analysts actually need, including the expected frequency of unlabeled full-text searches, the required response times for them and the fields that need field-level access restrictions. Ask the OpenSearch and Grafana teams to demonstrate those queries against a sample of your own log data, and record the storage used per day of retention for each. If your use case is mostly operational troubleshooting by service, Loki's model fits well. If it is threat hunting across message content, the answer depends on how much of that work you can convert into label-based queries.
How to measure log storage cost in your own environment
This sequence turns a vague question about log storage spend into a set of measured numbers from your own logs, so you can compare Loki and OpenSearch at the same volume, retention and query load. The output is a cost model built on your data and your cloud or data center terms, not on published benchmarks.
Sample a representative day of logs
Pick one ordinary weekday and one peak day from your busiest sources, then record raw ingest volume in gigabytes per day for each source, including the share that comes from applications, network devices, Kubernetes and security tools. Ask the platform team to confirm whether the figure is before or after any filtering or sampling in your shippers. You are done when you have a daily volume table with a named owner for each source and a note on which days you measured.
Count streams and labels for Loki
Run the same sample through a test Loki pipeline and count the active log streams, the label names in use and the distinct values for each label. Loki indexes only labels for each stream, so high-cardinality labels such as request IDs, user IDs or pod names created per run will multiply the index entries and the number of small chunks written to object storage. You are done when you have a stream count per source, a list of labels with their approximate distinct value counts, and a short list of labels to remove or move into log content.
Measure index and shard sizes for OpenSearch
Load the same day of logs into a test OpenSearch cluster with the mapping you would use in production, then record the primary store size, the replica count and the number of shards per index. OpenSearch builds a full-text inverted index and each shard is a full Lucene index, so the on-disk footprint depends on field mappings, the number of analyzed text fields and shard sizing choices. You are done when you have the total primary and replica storage per day, the shard count per index and the heap and disk headroom your test nodes show under the load.
Test a realistic query set on both platforms
Write a fixed list of queries your analysts and on-call engineers run, such as a 15-minute error search for one service, a 30-day search for a specific user across several sources, and a full-text search for an indicator of compromise. Run each query on both platforms against the same data and record the response time, the scope of the time range and the number of streams or shards touched. Keep the list short enough that you can repeat it and note which queries your team would not be able to answer in Loki without changing labels. You are done when every query has a result from both platforms and a yes or no on whether the answer was usable.
Model retention tiers for each platform
Define the retention periods your policy or regulator requires for each log class, then split them into hot, warm and cold tiers. For Loki, record whether retention is enabled, whether it applies globally, per tenant or per stream selector, and how long each rule keeps chunks in object storage. For OpenSearch, record the index lifecycle or tiering approach you would use and how many copies of each index you keep. You are done when you have one table per platform showing days retained per tier and the stored volume each tier creates from the measured daily figures.
Price object storage and block storage with your terms
Take the stored volumes from the retention model and apply the rates from your own cloud contract or data center chargeback model, separating object storage capacity, block storage capacity, IOPS or throughput charges, snapshot or backup storage, and egress where it applies. Ask your finance or cloud team to confirm whether the rates are list prices, negotiated rates or internal cost allocations. You are done when you have a monthly storage cost per platform for each tier, with a line for compute and support staff that you add separately, and a list of the rate assumptions to confirm before a quote.
Compare the results and document the assumptions
Place the two cost models side by side and highlight which inputs moved the answer most, such as label cardinality, replica count, retention length or query frequency. Record each assumption with its source and the person who confirmed it, and note where a result is an estimate rather than a measurement. Share the model with the vendor or partner you are evaluating so they can review the same inputs. You are done when the team agrees on the assumptions and the one or two drivers that would change the decision.
How deployment mode changes the storage bill
Loki's monolithic mode runs as a single binary and is the documented fit for volumes up to about 20 GB of logs per day. At this scale the storage bill is dominated by the object store that holds compressed chunks and the index, plus the compute for one process. There is little to tune beyond retention, so the cost conversation is mostly about how much history you keep.
- Fewest moving parts: one binary means one deployment to patch, monitor and back up, which keeps labor cost low.
- Object storage holds the data: chunks and index sit in S3, Google Cloud Storage or Azure Blob Storage, so storage spend scales with retained volume rather than with node count.
- Filesystem and MinIO are not the production default: the docs note that local filesystem and S3-compatible stores such as MinIO are supported but not typically recommended for production, which can change your hardware and support costs.
- High availability needs planning: confirm how you run redundant monolithic instances against shared object storage before counting on this mode for critical logs.
- Retention is off by default: the compactor keeps logs indefinitely until retention is enabled, so set it explicitly or the bill grows without limit.
Confirm the daily volume you will actually ingest, including peak days, before you commit to this mode.
Simple scalable mode separates read, write and backend targets and is documented for volumes approaching 1 TB per day. It sits between a single binary and a full microservices layout, so its cost profile combines more compute for read and write paths with the same object storage bill. The documentation states that this mode is being deprecated and will be removed with Loki 4.0, which makes it a poor base for a new build even though it is common in existing deployments.
- Separate scaling of read and write paths: you add read or write capacity independently, which matters once query load and ingest load diverge.
- Migration cost later: moving off a deprecated mode means a planned change to the deployment, not just an upgrade, so budget the effort in advance.
- Compute shape is harder to predict: sizing read and write targets depends on your query patterns, so pilot with representative searches.
- Storage stays in object storage: the mode does not change what you pay per gigabyte, only how many processes you run to serve it.
- Version pinning matters: the removal date is tied to Loki 4.0, so the version you run determines how long this layout is supported for you.
Confirm which Loki version you will run and whether your deployment will still be on a supported mode when you expect to upgrade. Do not rely on simple scalable mode for a new build without a written plan for that move.
Microservices mode is the documented choice for very large clusters, where each component scales on its own. Its storage bill is still driven by retained compressed data in object storage, but the total cost of ownership rises with the number of components, the Kubernetes capacity they need and the staff time to run them. For most teams this layout is justified by scale and query concurrency, not by storage price alone.
- Independent scaling per component: ingestion, querying and compaction can be sized separately, which helps when one workload dominates.
- Kubernetes operating effort: the layout typically runs on Kubernetes, so the platform team carries upgrades, storage classes and monitoring for each component.
- Object storage requests add up: a larger number of components can increase object store request volume, which you should model with your provider's pricing.
- Retention and compaction need care: compactor placement and retention rules affect both cost and query performance at this scale.
- Staffing is the largest line: the engineering time to operate the cluster is usually larger than the storage bill itself at this volume.
Ask for a written sizing estimate from your implementation partner that lists the components, replica counts and object store request assumptions for your daily volume.
OpenSearch does not change cost by deployment mode in the same way. Its cost follows shard planning and cluster sizing: each index is split into shards, and each shard is a full Lucene index with its own memory and disk footprint. The cluster tuning guidance asks you to size shards and nodes against the data you expect to hold, so the bill rises with the number of shards, replicas and the data nodes needed to host them, not only with raw volume.
- Shards are the unit of cost: the number and size of shards per index determine how many Lucene indexes the cluster must maintain and search.
- Replicas multiply the footprint: each replica is a further copy of the data, so the storage bill depends on the replica count you choose.
- Node count follows shard count: adding data nodes is a common response to shard growth, which adds compute, memory and storage together.
- Index lifecycle decisions move the bill: how long you keep hot, warm and cold data changes how many nodes you need at each tier.
- Upgrades carry effort: rolling upgrades are supported from the Elasticsearch versions listed in the FAQ, so confirm your starting version before planning.
Ask your implementation partner for a shard and node sizing worksheet based on your daily volume, retention period and replica count, and compare it line by line with a Loki sizing for the same workload.
How licensing and support affect total cost
License fees are unlikely to separate these two platforms on the invoice. Grafana Loki is licensed under AGPLv3, a change Grafana Labs announced on April 20, 2021 when it moved Loki and its other core projects from Apache License 2.0. OpenSearch is Apache-2.0 licensed, and its FAQ does not describe any paid edition. Both can be self-run without a license purchase, so the budget question is who carries the operating work. The AGPL term matters mainly if you modify Loki and offer it to users over a network, which your legal team should confirm against your own use. Do not let the license decision stand in for the cost model.
The OpenSearch Software Foundation is a Linux Foundation project whose board includes members such as AWS, IBM, SAP and Uber, but the Foundation is not involved in technical oversight of the OpenSearch project. Technical direction comes from the project itself, so an Apache-2.0 label does not give you a vendor-backed support contract. For OpenSearch, plan for recurring work: applying minor releases (OpenSearch 3.9.0 followed 3.8.0 on August 4, 2026, and the project targets a new minor about every eight weeks), tracking maintenance windows, and hardening the Security plugin. For Loki, plan for upgrades to the deployment mode you choose, since the Loki documentation says simple scalable mode will be removed in Loki 4.0. Ask any support provider which versions it covers and for how long.
Grafana Enterprise Logs is a separate commercial option to evaluate, not a cost baseline. Its documentation describes it as the enterprise version of Loki, and it adds capabilities for multi-tenant access control. Request written pricing and support terms from Grafana Labs for the exact scope you need, and compare them with your internal staffing for upgrades, backups and security patching. Budget for those staffing and quote lines in both cases, because they recur for as long as the cluster runs.
Questions buyers ask about log storage cost
Which is cheaper to run, Loki or OpenSearch?
Neither is cheaper in every case, because the answer depends on daily volume, query habits and how much of the bill comes from people and hardware. Loki indexes only labels and keeps compressed chunks in object storage, so its main recurring cost is usually the object store plus compute for ingest and queries. OpenSearch builds full-text inverted indexes split into shards, each a full Lucene index, so its recurring cost is usually the nodes, disks and memory needed to hold those indexes. Ask each vendor or your own team to model your actual ingest rate, retention and query load before comparing totals.
What drives monthly log storage spend the most?
The main drivers are daily ingest volume, how long you keep logs, how much data is indexed, and how often you query it. For Loki, label cardinality and the number of streams affect the index and chunk layout, while object storage pricing and request counts shape the bill. For OpenSearch, the amount of text that gets indexed, replica count, shard sizing and the disk and heap needed to keep indexes searchable tend to dominate. Compression ratios differ by log type, so measure with a sample of your real logs rather than a generic figure.
Can we cut log storage cost by shortening retention?
Yes, shorter retention lowers the stored volume on either platform, but the effect differs by design. In Loki, retention is applied by the compactor and is disabled by default, so logs stay indefinitely until you enable retention_enabled and set rules; each stream rule is at least 24 hours. Confirm that your compactor is running and that deletion behaves as you expect before you rely on it for budget. In OpenSearch, retention is usually handled through index lifecycle management or rollover policies, so confirm the exact policy and snapshot strategy with your own environment. Shorter retention can also conflict with audit or incident response needs, so agree the retention periods with your compliance owner first.
How much work is it to run Loki compared with OpenSearch?
Both need planned operations, but the work sits in different places. Loki requires an object store you trust for production, a deployment mode chosen for your daily volume, a log shipper such as Grafana Alloy, and an authenticating reverse proxy because Loki has no built-in authentication layer. OpenSearch requires cluster sizing, shard and index management, node upgrades, and configuration of its Security plugin for authentication and role-based access control. The Loki simple scalable mode is being deprecated and will be removed with Loki 4.0, so factor that into any plan. Ask your team to list the components each platform adds to your environment before estimating effort.
What skills does our own team need to run either platform?
Your team needs object storage and Kubernetes or VM operations experience for Loki, plus an understanding of label design, since poor label choices create many streams and make queries expensive. For OpenSearch, your team needs experience with cluster health, shard planning, index lifecycle policies, JVM memory tuning and rolling upgrades. Both platforms need someone who can own on-call alerts for ingestion failures, storage growth and query latency. If those skills are thin, confirm how much training or external support you will need before you choose.
What do we give up in query power by choosing Loki?
Loki's index covers labels only, so searches for arbitrary text inside log lines scan the matching chunks rather than consulting a full-text index. That keeps storage cheap, but broad text searches over large time ranges will be slower and more expensive to run. OpenSearch's inverted index and Lucene-based search handle free-text queries, aggregations and security analytics more directly. If your team depends on ad hoc text search or detection content that relies on full-text matching, test both platforms with your own queries before committing.
Can DeployOpen help us measure and implement a log storage plan?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so it can help with sizing, deployment, retention configuration and runbooks for either Loki or OpenSearch. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask for a measurement step that uses your real ingest and query samples so the scope reflects your environment.
When storage cost should decide the choice
Let storage cost decide only when your queries are mostly label-based and your retention is long. Loki indexes labels for each log stream and keeps compressed chunks in object storage, so most of the bill follows the volume you keep and the object store you pay for. If engineers usually filter by service, namespace, environment or host and then scan matching lines, that model fits well. Under the same conditions, OpenSearch pays for a full-text inverted index on every field it indexes, split across shards that are each a full Lucene index, plus the heap and disk to hold them. Before you decide, pull a week of real queries from your current stack and count how many need text search across message bodies. Confirm with the Loki retention documentation how retention is set per tenant or per stream selector, since retention is disabled by default and logs are kept indefinitely until you enable it.
Choose OpenSearch even at higher storage cost when frequent unlabeled full-text search and security analytics are core work. Detection rules, threat hunting and investigations that pivot on arbitrary strings or fields that were never promoted to labels are where OpenSearch's index earns its cost. Keep the OpenSearch Security plugin in scope from the start, since its role-based access control, field-level security and audit logs are part of the design rather than a later add-on. The Loki side needs an authenticating reverse proxy in front of it, which is extra work your team must own. Because OpenSearch is Apache-2.0 with no paid edition described in its FAQ, the cost difference comes from hardware, storage and operating effort rather than licensing. Your team's existing Elasticsearch 7.10 knowledge can reduce migration effort on the OpenSearch side, because OpenSearch is wire-compatible with that version. Test this with your own team and client tooling before counting it as a saving.
Treat the choice as hard to reverse either way. Log history, dashboards, alert rules and every shipper configuration are tied to the query language and storage model you pick, so moving later means re-ingesting or running two stores during a transition. Ask any implementation partner for a written migration estimate that covers retained history, query rewrites and shipper changes before you commit. Ask vendors and your own environment to confirm sizing against your daily volume, retention period and query mix, because those three inputs drive the result far more than the license does.
How DeployOpen helps you measure and implement log storage
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Loki vs OpenSearch storage cost, we start by measuring your real ingest, retention and query patterns so the storage decision rests on your numbers, not on a generic estimate.
How we scope
- We agree a written scope before work starts, covering log sources, daily volume and retention periods.
- The scope names which query patterns, dashboards and alerts must keep working on either platform.
- We confirm object storage, shard or chunk layout, and the network and identity boundaries your team requires.
How we build
- We deploy the chosen log store with the object storage, retention and tenant settings agreed in scope.
- We configure shippers such as Grafana Alloy or Fluent Bit so label design and field handling match the plan.
- We test ingest rates, query latency and retention jobs against the sizing assumptions in the written scope.
How we hand over
- You receive configuration, sizing worksheets and a cost model showing which drivers move storage spend.
- Runbooks cover retention changes, backup, upgrades and the steps to add log sources or tenants.
- Documentation records licensing and edition details so your procurement and legal teams can verify them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can review retention and storage growth periodically so cost assumptions stay current with your volume.
- Support scope, response expectations and upgrade windows are written into the retainer before it starts.
