Loki or OpenSearch: when each one fits your logging estate
Loki fits label-driven troubleshooting and low-cost retention, while OpenSearch fits free-text search and security analytics. A team running its own infrastructure has to decide which of those jobs dominates its logging estate, because the two platforms store and query logs in fundamentally different ways. Loki indexes only the labels attached to each log stream and keeps compressed chunks of log content in object storage such as S3, so engineers who know the service, environment or workload name get fast answers and storage stays inexpensive. OpenSearch builds an inverted index over log text, so analysts can search any term or field, at the cost of more index storage and cluster capacity. Start by listing the questions responders and security analysts ask each week, then sort them into label lookups and content searches.
Licensing and deployment mode often settle the question before query performance does. Loki is licensed under AGPL-3.0, a copyleft license whose network-use terms can matter if you modify Loki and offer it to users over a network, so have counsel review those obligations against your internal and customer-facing use. OpenSearch is Apache-2.0, which many platform teams find simpler to approve, though you should still confirm the terms for any plugins you add. Check the Loki deployment modes guide before you commit, because the Simple Scalable mode will be removed in Loki 4.0. A team that adopts it now needs a migration plan, and a team that runs the distributed components needs a named owner for each one. Confirm which OpenSearch topology your team can operate, including shard planning and node roles, before sizing hardware.
Retention volume is the cost driver most teams underestimate, and it can reverse the answer. For Loki, most recurring spend is object storage capacity and the compute that runs its components, so long retention on inexpensive storage is its strongest case. For OpenSearch, every indexed field consumes disk and memory, so long retention of full-text indexes usually means more nodes and more storage. Ask any vendor or implementation partner for a written quote that separates one-time build work from recurring storage, compute, licensing and support costs, and state your daily ingest volume and retention period in the scope. Then run a trial on a representative slice of production logs, using your most common saved queries, and measure how long each one takes on each platform.
Which platform fits each logging scenario
This table maps common logging scenarios to the platform that usually fits better and names the condition under which the other one would win. Read each row against your own query volume, retention period and team skills, since the right answer depends on how often you search log contents and how long you keep them.
| Scenario | Better fit | Reason and when the other platform wins |
|---|---|---|
| Kubernetes application troubleshooting | Loki | Label-based stream selection suits queries by namespace, pod or container. OpenSearch wins if engineers routinely search for arbitrary error strings across all logs. |
| Long-term audit retention | Loki | Compressed chunks in object storage such as S3 keep long retention on cheaper storage. OpenSearch fits if auditors need fast full-text queries over years of history, which raises index and shard costs. |
| SIEM-style detection with free-text search | OpenSearch | Inverted indexes over log contents support fast keyword and field searches for detection rules. Loki fits only if detections rely on labels and you accept scanning raw chunks for content matches. |
| Grafana-centric observability | Loki | Loki is part of the Grafana stack and pairs with metrics and traces in one interface. OpenSearch is the better choice if your dashboards and analysts already run on OpenSearch Dashboards or the wider OpenSearch ecosystem. |
| High-cardinality fields such as user IDs or request IDs | OpenSearch | Full-text indexing handles unique values without turning each one into a stream label. Loki works well if these fields stay in log lines and you query them infrequently. |
| Cost-sensitive, high-volume log ingestion | Loki | Indexing only labels keeps index growth small. OpenSearch can suit lower volumes or workloads where search speed justifies more storage and compute, so model both with your own ingest rate. |
| Licensing constraints on internal modifications | OpenSearch | OpenSearch is Apache-2.0 licensed. Loki is AGPL-3.0, so confirm with counsel how the network copyleft terms apply if you modify and offer it to users. |
| Deployment flexibility and operating model | Confirm with your team | Loki's Simple Scalable mode will be removed in Loki 4.0, so plan on microservices or single-binary modes. Choose OpenSearch when your team already operates its clusters and shard layout well. |
How each platform stores and queries logs
Loki and OpenSearch both ingest logs at volume, but they make opposite bets about what to index. The choice shapes which components you run, where your data sits, and how much daily attention the cluster needs.
Label-only indexing in Loki
Loki indexes only the labels attached to each log stream, not the log lines themselves. Compressed chunks go to object storage such as S3, so the index stays small relative to the data. The trade-off is that queries filtering on message content must scan chunks, so label design matters. Check that your team can name the labels it will filter on before ingestion starts, because changing them later means rebuilding streams and dashboards.
Full-text inverted index in OpenSearch
OpenSearch builds an inverted index over log content, which supports fast free-text search, aggregations and detection rules across fields. Each index is split into shards, and every shard is a full Lucene index with its own memory and disk footprint. This suits security analytics where analysts search arbitrary fields, but index size and heap pressure grow with retained data. Confirm the field mapping approach and index lifecycle policy with your search team before sizing the cluster.
Components and data placement
A Loki deployment runs distributors, ingesters, queriers and query components, with chunks and index data held in object storage that you provision and back up. OpenSearch runs data, master and often dedicated coordinating nodes on local disks, with snapshots sent to a repository you configure. Ask each vendor or your architect which components you must run, where durable copies live, and how restores are tested. Object storage durability and snapshot repository policy become core parts of your control evidence.
Deployment mode changes in Loki 4.0
Loki's Simple Scalable deployment mode will be removed in Loki 4.0. Teams that adopt this mode today should plan a move to a supported topology before upgrading to that major release. Treat the migration as a scheduled change with its own test window, backup of the index and chunk stores, and rollback plan. Confirm the current deployment mode guidance and the Loki 4.0 timeline in the deployment documentation before committing to a layout.
Shard and index management
In OpenSearch, shard count, shard size and index rollover determine query speed, recovery time and heap use. Oversized or too many shards slow cluster state operations and restores, so index lifecycle policies and rollover rules become day-two work. Loki has no shard tuning in this sense, but it needs retention, compactor and chunk storage settings reviewed as volume grows. Ask for a documented retention and rollover policy and a test showing how long a node recovery takes at your expected volume.
Licensing and stored data
Loki is licensed AGPL-3.0, which carries source disclosure obligations if you modify and offer it as a network service. OpenSearch is Apache-2.0, which is typically simpler for internal use and embedding. Both keep logs in infrastructure you control, so licensing review should cover your modifications, not just the default install. Have legal confirm whether AGPL terms apply to your planned use before selecting Loki for a shared logging service.
How query patterns drive storage and query cost
The cost difference between Loki and OpenSearch starts with where each system does its work. Loki indexes only the labels attached to each log stream, not the log contents, so its index stays small and cheap to hold. The price is paid at query time: a filter on message text has to read and decompress the compressed chunks in object storage that match the selected labels and time range. OpenSearch does the opposite. Each shard is a full Lucene index with an inverted index over the terms in your documents, so ingest does more indexing work and the index grows with the text you keep, and that index needs memory and disk to stay responsive. Your storage and memory bill for OpenSearch follows content volume; your query bill for Loki follows how much data a search has to scan.
Five drivers shape both sides, and they interact. Ingest volume raises storage in both systems, but in OpenSearch it also raises indexing CPU and index size, while in Loki it mostly raises chunk storage and the amount a broad query must read. Retention period multiplies whatever you ingest, and it is the lever most often underestimated in a quote. Label cardinality is the Loki-specific risk: every distinct combination of label values creates a new stream, so high-cardinality labels such as user or request identifiers fragment the index and slow ingestion. Shard count is the OpenSearch counterpart, since each shard carries fixed overhead and too many small shards waste heap. Query frequency matters for both, but a dashboard that refreshes often over a wide time range costs far more in Loki, where each run rescans chunks, than in OpenSearch, where the query hits a warm index.
Measure these in your own environment before you compare vendor claims. Record daily ingest in gigabytes for each log source, the retention each compliance owner requires, the number of distinct values for every label you plan to use, and the query mix: how many saved searches, alerts and investigations run per day and over what time windows. Then ask for the detection and investigation queries your SOC actually runs and test them against a representative sample. Ask any implementation partner to size storage, memory and shard layout from those measurements and to state its assumptions in the written scope. Confirm current deployment and index guidance with Grafana Loki's deployment modes documentation and the OpenSearch introduction, since both products change their recommended layouts over time.
Capabilities that separate Loki and OpenSearch
This table sets Grafana Loki against OpenSearch across indexing, search, storage, analytics, alerting, licensing and deployment. Read each row as a question to answer for your own log volumes and query patterns, and treat the cells as the starting point for vendor confirmation rather than a final verdict.
| Capability | Grafana Loki | OpenSearch |
|---|---|---|
| Indexing model | Indexes only labels for each log stream, not log contents | Builds an inverted index over full text, split into shards that are each a Lucene index |
| Full-text search | Limited to label selection plus filtering of stored log lines at query time | Built for full-text search across indexed fields |
| Object storage use | Stores compressed chunks in object storage such as S3 | Index data sits on node-local storage; confirm current options for snapshots and tiering |
| Best-fit query pattern | Known label sets, time-range scans and log line filtering during investigations | Ad hoc searches across many fields and high-cardinality attributes |
| Analytics and dashboarding | Pairs with Grafana for log exploration and dashboards | Ships its own dashboards and analytics layer; confirm specific security analytics features with the vendor |
| Alerting | Alerting built around log-derived queries; confirm rule and routing options with Grafana | Alerting and monitoring features are part of the platform; confirm available options for your version |
| License | AGPL-3.0 | Apache-2.0 |
| Deployment modes | Simple Scalable mode will be removed in Loki 4.0; plan around the documented modes | Confirm supported cluster topologies and sizing guidance for your version with the vendor |
How AGPL-3.0 and Apache-2.0 affect your use
Internal use means your staff, contractors and systems operate Loki or OpenSearch inside your own environment, and nobody outside the organization receives copies or runs a modified copy for them. This is the most common case for security and platform teams running logs for their own estate, and it is where the two licenses are least likely to create new duties. Confirm the boundary with counsel before you rely on it, because the answer depends on who your users are and where the code runs.
- Loki (AGPL-3.0): Running unmodified Loki for your own log pipeline does not by itself change your obligations. If you modify it and distribute the modified code outside your organization, the license conditions apply.
- OpenSearch (Apache-2.0): Internal deployment carries no source sharing duty. Keep the license and notice files in your build in case you later redistribute.
- Internal patches: Changes to Loki or OpenSearch that stay inside the organization are the case to review. Record which components you change, since that list drives the review later.
- Contractors and managed providers: Whether a partner operating the stack for you counts as internal use depends on who controls the system and who receives the code. Settle this with counsel and in the written scope of work.
Check whether any internal modification will leave the organization, including through a support vendor, before you assume internal use is the simplest case.
Offering a service means exposing a modified platform to people outside your engineering group, such as customers, separate business units or a managed log service sold to others. Licenses treat network access differently, and this is where the two platforms diverge most. Keep a record of every change so you can answer questions quickly if an obligation applies.
- Loki (AGPL-3.0): The AGPL is written to reach software that users interact with over a network. Counsel should confirm whether remote users of a modified Loki trigger a duty to offer them the corresponding source code.
- OpenSearch (Apache-2.0): Apache-2.0 is a permissive license without a network copyleft provision. Hosting a modified OpenSearch for others generally does not by itself require publishing your changes, but confirm the notice requirements.
- Shared internal services: Business units that consume a shared stack may count as users in the license sense. Map who interacts with the modified platform before deciding which duties apply.
- Add-ons and UI components: Confirm the license of every plugin, dashboard or interface component you bundle, since the supplied facts cover only the core projects and add-ons may carry other terms.
Ask counsel to review the exact modification and access pattern, not only the category of service, before you offer it to anyone.
Embedding means shipping Loki or OpenSearch as part of software, an appliance or a hosted product you sell, so the platform becomes a component of something larger. Distribution is the trigger that matters most here, and the two licenses set different conditions on it. Plan packaging, architecture and notice files early, because changes after the first release are costly.
- Loki (AGPL-3.0): Distributing Loki in a product generally brings AGPL source obligations into play for Loki and for modifications to it. Counsel should assess whether your own code forms a combined work with it.
- OpenSearch (Apache-2.0): Apache-2.0 allows redistribution in source or binary form when you include the license text and required notices, and it includes an express patent license from contributors. Keep attribution in your product documentation.
- Process boundaries: Separate processes that communicate over an API are often analyzed differently from code linked into your binaries. Counsel should decide how your architecture is treated under each license.
- Mixed bundles: A product that ships both platforms must satisfy both sets of conditions, and one combined notice file may not be enough.
Ask counsel to review the distribution model, the architecture and the notice bundle together before the first shipment.
What drives the running cost of each platform
This table lists the cost components that shape the running cost of Grafana Loki and OpenSearch, including who is paid, what recurs and what drives each cost up or down. Use it to structure a written quote request, since the supplied research gives no prices for either platform.
| Cost component | Loki (label index, object storage) | OpenSearch (inverted index, cluster nodes) |
|---|---|---|
| Storage infrastructure | Compressed chunks in object storage such as S3, with a small label index. Recurring cost scales with retained log volume and object storage pricing from your provider. | Shards are full Lucene indexes on node disks, so storage is typically provisioned as block or local disk per node. Recurring cost scales with indexed volume plus replicas and the headroom you keep. |
| Compute and memory | Read and write components run as separate services, and query cost depends on how many streams and how much data a query scans. Confirm node sizing with the Loki deployment mode documentation. | Data nodes need memory and CPU for indexing and search, and heap sizing and shard count drive node count. Expect recurring compute for every node in the cluster, including replicas. |
| Skills to operate | One-time effort to learn label design, since poor labels raise query cost. Recurring effort for object storage access, retention and compactor tuning. | One-time effort to design index mappings and shard strategy. Recurring effort for cluster health, index lifecycle and security analytics content, often carried by an in-house team or a paid partner. |
| Support and licensing | Loki is AGPL-3.0, so the software itself has no license fee. Support is a separate, recurring cost if you buy it from a vendor or partner; confirm terms in writing. | OpenSearch is Apache-2.0, so the software itself has no license fee. Support, managed hosting or security plugins sold by third parties are recurring costs; ask each provider what is included. |
| Upgrades and maintenance | Upgrades are recurring labor for your team or a retainer. Confirm how the Simple Scalable deployment mode removal in Loki 4.0 affects your migration plan and its effort. | Minor and major upgrades recur, and version compatibility of plugins and dashboards adds testing time. OpenSearch 3.9.0 was released on September 29, 2026, so plan upgrades against the release you deploy. |
| Retention and data growth | Retention is set by object storage lifecycle rules, so long retention is mostly a recurring storage cost that rises with volume. Ask how deletion and compaction are handled. | Retention is handled through index lifecycle policies, and longer retention raises both disk and replica cost. Hot, warm and cold tiers, where you use them, change the recurring cost profile. |
| Implementation services | One-time fees for architecture, label design, migration and hardening, billed under a written fixed scope if you use a partner. | One-time fees for cluster sizing, index design, detection content and hardening, billed under a written fixed scope. Include ongoing retainer terms separately. |
Moving logs from one platform to the other
This sequence moves log ingestion, search and alerting from Loki to OpenSearch or the reverse without losing the evidence your security and operations teams depend on. It ends with a cut-over that both platforms have been checked against the same sample of real queries and alert outcomes.
Inventory sources, labels and consumers
Your platform or logging engineers list every log source, the stream labels or index fields each one produces today, and every team that queries logs or receives alerts. Security analysts should flag the detection rules they rely on most. The output is a written inventory that maps each source to its destination platform, its parser and its owners. The step is done when every source has an owner who has signed off on the mapping.
Map labels to fields or fields to labels
The core design decision is how the data model changes. Loki indexes only labels for each stream and leaves log content unindexed, so high-cardinality values such as user IDs or request IDs usually stay inside the log line. OpenSearch builds an inverted index over fields, so those same values become searchable fields. Moving to Loki means choosing a small, stable label set and extracting anything else at query time. Moving to OpenSearch means defining mappings and index templates for each field you need to filter on. The output is a mapping document reviewed by the security team, and the step is complete when a sample of events maps cleanly in both directions.
Dual-run ingest into both platforms
Ship the same log streams to the current and the target platform at once, using the mapping from the previous step. Whoever operates the collectors, such as the team that runs your shipper configuration, adds the second destination and confirms that event counts, timestamps and parsing results agree on both sides for a representative period. Expect to tune parsers and label sets during this phase. The output is a comparison report of event counts and parse failures per source. The step is complete when the differences are explained and accepted by the owners.
Rebuild queries, dashboards and alerts
Queries do not transfer. LogQL and OpenSearch query DSL or PPL express filters, aggregations and joins differently, and dashboards and alert rules must be rewritten against the new data model. Work through the inventory from step one, starting with the alerts that drive incident response and the detection rules owned by security. Each rewritten item is tested against the same known events in both platforms. The output is a rebuilt set of dashboards and alert rules with a test result for each. The step is complete when every alert fires on the test events and no alert fires on the control set.
Rebuild index templates, retention and access controls
Retention, storage tiers and access control are configured differently on each side. In Loki, retention and storage behavior depend on the deployment mode and object storage configuration, so confirm the supported mode for your version in the Loki deployment documentation before you commit. In OpenSearch, index templates, shard layout and index lifecycle policies carry much of the storage and performance design, and they should be set before data arrives. Confirm role and tenant mapping with your identity team. The output is a documented configuration for retention, access and lifecycle, reviewed by compliance. The step is complete when a test user sees only the data their role permits on both sides.
Decide what happens to historical data
Historical logs are the step most often underestimated. Raw logs can usually be carried over because Loki keeps compressed chunks in object storage such as S3, so exporting or copying those objects, or keeping the old store read-only, is a practical path. OpenSearch indexes are not portable in the same way, so older data is often kept on the existing platform for its retention period or reloaded from raw files through a pipeline. Record which evidence must be retained for audits or investigations, and who approves the decision. The output is a signed retention decision per data set. The step is complete when legal, compliance and security have each recorded that decision.
Cut over and retire the old platform
Switch alert routing and collector destinations to the new platform in a planned change window agreed with the operations team. Keep the old platform available in read-only mode for the period set in the historical data decision, so investigations can still reach older events. Watch alert volume and missed-event checks closely for the first days after the switch. The output is a cut-over record listing changed routes, alert owners and the read-only access arrangement. The step is complete when the new platform carries all production traffic and the old platform is retired only after the agreed retention period ends.
Where logging implementations usually run long
The most expensive overruns in a logging project come from decisions made before the first log line is shipped. For Loki, the decision that matters most is label design. Loki indexes only the labels attached to each log stream, not the log contents, so labels such as a per-request ID, user name or client IP create a flood of tiny streams that slow ingestion and queries. Teams often discover this after dashboards are built on top of the labels. For OpenSearch, the equivalent trap is mapping and shard sizing. Dynamic mapping can turn one unexpected field into thousands of fields, and each index is split into shards that are each a full Lucene index, so a poor shard count or an unplanned rollover policy leaves a cluster either oversharded or with a few oversized shards that are slow to recover. Both platforms need the same upfront answer on sizing, retention policy and which team owns each index or tenant.
Identity and alerting add their own work, and they are easy to underestimate. Access control has to cover who can read which tenants or indexes, who can change retention, and who can see sensitive fields such as authentication events. Confirm with your identity team how each platform's authentication and role mapping will integrate with your directory, and confirm which alerting path your security operations team already uses, since alert rules built on LogQL or OpenSearch query syntax will need to be rewritten if the platform changes. Retention is also a recurring cost decision, so agree the retention periods for each log class with the data owners before implementation, not after the first storage invoice.
Before quoting, the client must supply four things: administrative access to the target environments (cloud accounts, data center hosts or air-gapped networks), named data owners who can approve which log sources, fields and retention periods are in scope, a representative sample of production log volume and query patterns, and a list of compliance obligations that the logs must support. Ask the implementation partner to state these inputs in the written scope, and ask the platform owner to confirm the current deployment mode guidance in the Loki deployment modes documentation before sizing the object storage and read and write paths.
Questions buyers ask before choosing a logging platform
What drives the cost of running Loki compared with OpenSearch?
Storage layout and query volume drive most of the difference. Loki indexes only labels for each log stream and keeps compressed chunks in object storage such as S3, so its index stays small and the bulk of spend tends to be object storage capacity and the compute that scans chunks at query time. OpenSearch builds an inverted index over log contents, splitting indexes into shards that are each a full Lucene index, so spend leans toward memory, disk and node count. Ask any quote to separate infrastructure (who pays the cloud or hardware bill), software (none for the Apache-2.0 OpenSearch core, but confirm which add-ons you need), and DeployOpen's fixed-scope work, and to state how retention and daily ingest were assumed.
How long does it take to implement a log platform?
No duration for either platform is included in the researched facts, so treat any timeline as something to get in writing rather than assume. Implementation length depends on the number of log sources, parsing and field mapping work, retention tiers, access control, and how many environments must be built. Most DeployOpen engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts. Ask for a timeline tied to a named list of sources and deliverables, and confirm which parts depend on your change approval and access provisioning.
What does the work need from our own team?
Both platforms need people who understand their storage and query model, and the skills differ. Loki work leans on label design, query language familiarity, object storage lifecycle policies and cache sizing. OpenSearch work leans on index lifecycle management, shard sizing, cluster capacity planning and mapping design. Your team will also need to own access control, alerting rules and on-call response. Name the people who will receive handover documentation and who will approve changes, because those roles decide whether the platform stays healthy after the engagement ends.
Can our team run the logging platform without outside help?
Yes, if you have engineers who can operate the chosen stack in your own infrastructure, and both options are self-hostable under open-source licenses. The practical question is whether you have the capacity to build the pipeline, tune it, patch it and respond to incidents. Teams with a small platform group often start with a scoped implementation and documentation, then decide what to keep in-house. Retainers for ongoing support, upgrades and continuous testing are available if you want a standing partner instead of a one-time build.
Which platform fits compliance-driven log retention?
Choose based on how you will search retained logs during an assessment. Loki suits retention where most reviews filter by labels such as service, environment or tenant, and where long-term storage in object storage is the main cost concern. OpenSearch suits investigations that need full-text search across log contents and security analytics on arbitrary fields. Compliance readiness in either case means documented retention periods, access logging, integrity controls and tested restores. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Confirm your required control mapping with your assessor before design starts.
What should we confirm about licensing before deploying?
Confirm the license of each component you deploy and what your use triggers. Grafana Loki is licensed under AGPL-3.0, and that license carries network-use obligations for modified versions, so ask legal how it applies to your deployment and any changes DeployOpen makes. OpenSearch is licensed under Apache-2.0. Also confirm which OpenSearch plugins, dashboards components and collectors you use, since each has its own license terms. Ask for a written list of components and licenses in the scope document, and confirm any version or support dates with each vendor, since release timing changes.
Which deployment modes does each platform support?
Both can run in your own infrastructure, including private cloud, data centers or air-gapped networks, which is where DeployOpen works. For Loki, check the Loki deployment modes documentation, because the Simple Scalable deployment mode will be removed in Loki 4.0, which affects long-term design. For OpenSearch, check the deployment guidance for your cluster topology, node roles and whether you need multiple availability zones. Ask the implementation team to confirm which mode fits your target version, and document the upgrade path before you commit.
How DeployOpen helps choose, implement or migrate your logging stack
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Loki vs OpenSearch, we start by mapping your query patterns, retention needs and security analytics requirements onto the platform that fits them, then carry the chosen stack through to a documented, supported deployment.
How we scope
- Review which queries your teams run most, such as label-based stream lookups or free-text and detection searches.
- Confirm log volume, retention periods and object storage or disk options with your infrastructure owners before choosing.
- Agree the deployment mode, licensing review and written deliverables for Loki or OpenSearch in a fixed-scope document.
How we build
- Deploy the selected platform in your own environment with configuration matched to the agreed ingestion and query profile.
- Integrate log sources, identity, access controls and alerting paths so the stack works with your existing operations tools.
- Test ingestion, query performance and failure behavior, and harden the deployment against the controls your assessors expect.
How we hand over
- Document architecture, configuration, storage sizing assumptions and the cost drivers your team will need to watch.
- Walk your operators through backup, upgrade and retention procedures so your staff can run the platform day to day.
- Deliver evidence packs that show configuration and control status for your compliance assessors, who issue any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
- Plan version upgrades around release schedules, such as the Loki 4.0 removal of the Simple Scalable mode, before they become urgent.
- Confirm with your team which support channels, response expectations and upgrade windows apply before signing a retainer.
