Loki or OpenSearch: which log store fits your search and storage needs
Choose Grafana Loki if your team mostly answers questions like "show me the logs for this service in this environment during this window" and you are willing to keep long log history in object storage. Choose OpenSearch if analysts need to search arbitrary text across log bodies, run security analytics with detection content, or rely on field-level access controls inside the index. Loki indexes only labels for each log stream, not log contents, and stores compressed chunks in object storage such as S3. OpenSearch is Apache-2.0 licensed, builds an inverted index for full-text search, and descends from Elasticsearch 7.10, which makes it the more familiar path for teams migrating from that stack.
The decision turns on three things: the query patterns your analysts actually run, the daily volume and retention you must keep, and how your legal and procurement teams view AGPLv3 compared with Apache-2.0. Loki's AGPLv3 licence applies to Loki itself, and Grafana Labs moved Loki from Apache 2.0 to AGPLv3 on April 20, 2021, so confirm with counsel whether network-use obligations matter for your deployment. Loki has no built-in authentication layer and needs an authenticating reverse proxy in front of it, while OpenSearch's Security plugin already provides SAML, OpenID Connect, LDAP and role-based access control. Factor that authentication work into your effort estimate for Loki.
Before you decide, run a one-week query audit. Export the last 30 days of saved searches and alert rules, and mark which ones filter only on labels such as service, namespace or environment, and which need free-text matching on message bodies. If most queries are label-scoped and retention runs to months or years, Loki's object storage model is usually the stronger cost fit, and you should confirm the deployment mode with the Loki deployment modes documentation. If free-text and detection workloads dominate, OpenSearch's per-shard Lucene indexes are the better fit, and you should budget for heap, disk and shard planning from the OpenSearch introduction.
Which platform fits which log scenario
This table maps common logging scenarios to the platform that usually fits better, and the condition under which that holds. Read each row for the condition, not just the winner, because both platforms are sound choices in the right setting. The main takeaway is that label-indexed Loki suits label-driven troubleshooting and long retention on object storage, while OpenSearch suits investigations that depend on searching message content.
| Scenario | Better fit | Condition under which it holds |
|---|---|---|
| Infrastructure and application troubleshooting by labels | Loki | Your queries filter by stable labels such as cluster, service or namespace, and you read matching lines rather than search across arbitrary text. |
| Security investigations needing full-text search over message content | OpenSearch | Analysts must find unknown strings, IOCs or free-text fields across all events without knowing which labels to filter on. |
| SIEM-style analytics and correlation | OpenSearch | You need aggregations, field-level access control, document-level security and audit logs for analysts, and you accept the shard and index sizing work that comes with it. |
| High-volume, long retention on object storage | Loki | Most queries target recent data and you keep large volumes on S3-class storage. Confirm your own ingest rate and query mix before relying on this. |
| Small team wanting a single binary | Loki | Daily volume stays within the monolithic mode range the Loki docs describe, and you can run it behind an authenticating reverse proxy you manage yourself. |
| Access control and built-in authentication | OpenSearch | You need SAML, OIDC, LDAP or Kerberos login and role-based controls inside the log store. Loki needs an external authenticating proxy. |
| Planning for simple scalable deployment | Neither as a fixed choice | Loki simple scalable mode is being removed in Loki 4.0, so plan a monolithic or microservices layout. Confirm the current OpenSearch install path your team will use. |
How Loki and OpenSearch are built and what that means for operations
Loki and OpenSearch both store logs, but they spend resources in different places: Loki on labels and object storage, OpenSearch on full-text indexes and cluster state. The cards below cover the index design, storage layout, deployment modes, cluster model and upgrade path of each, and the operational questions each one raises for your team.
Loki indexes labels, not log lines
Loki indexes only the labels attached to each log stream and stores the log content as compressed chunks. Index size tracks the number of label combinations, so the main sizing risk is high-cardinality labels such as request IDs or user IDs, which multiply streams. Before you ship logs, define a short, stable label set, and test what your most common queries cost when they must scan chunks instead of using an index. Confirm the label budget your team will enforce.
Chunks and index live in object storage
Loki keeps compressed log chunks and its index in object storage, and the docs recommend Amazon S3, Google Cloud Storage or Azure Blob Storage for production. Local disks hold only caches and short-lived state, so a Loki node can usually be replaced without losing data. Your operational work shifts to the bucket: access policies, lifecycle rules, replication and cost monitoring. Check whether your organization already runs an object store that meets those requirements and whether the S3-compatible option you plan to use is supported for production.
TSDB is the index to plan around
TSDB is the recommended index store for Loki 2.8 and newer, and older index stores such as DynamoDB, Bigtable and Cassandra are deprecated. A new deployment should start on TSDB, and an existing one should confirm its schema configuration before any upgrade. Because the index is small relative to the data, query performance depends heavily on how many chunks a query must read. Ask your team to document the schema version in use and the upgrade path for each future Loki release.
Three Loki deployment modes
Loki offers monolithic mode for a single binary, documented for up to about 20 GB of logs per day, simple scalable mode with separate read, write and backend targets, documented for approaching 1 TB per day, and microservices mode for very large clusters. Simple scalable mode will be removed in Loki 4.0, so a new deployment that picks it now will need a migration later. Choose the mode by daily volume and team capacity, and confirm the Loki 4.0 release timing before you commit.
OpenSearch inverts every indexed term
OpenSearch builds an inverted index for full-text search, so every indexed term points to the documents that contain it. Memory, disk and CPU needs rise with the volume of indexed text, the number of fields and the number of shards. Node sizing is therefore a function of ingest rate, retention and the fields you index, not of label count. Ask for a sizing test on a sample of your real logs before you fix the node count.
Shards are full Lucene indexes
In OpenSearch, each index is split into shards, and each shard is a full Lucene index with its own files, merges and memory use. Shard count is set when an index is created, so a poor choice is expensive to correct, and too many small shards add overhead for every node. Plan shard counts per index and per time window, and set an index lifecycle policy so old indexes roll over and close. Confirm your planned shard size and retention with the team that will operate the cluster.
Cluster state and upgrades in OpenSearch
An OpenSearch cluster has master-eligible, data and coordinating roles, and it holds cluster state that every node must agree on. OpenSearch supports rolling upgrades from Elasticsearch 6.0 through 7.10 indices, and versions stay in maintenance for at least one year or until the next major version enters maintenance. Plan upgrades as rolling operations with a tested rollback path, and confirm which minor release your team will run and how long it stays supported.
Which deployment mode each platform supports at your volume
Loki's monolithic mode runs all components as a single binary. The Loki deployment modes documentation gives it as the option for smaller log volumes, up to about 20 GB of logs per day. It suits a single team, a lab or a first deployment, where one process to run, monitor and upgrade keeps the operating surface small. Storage still goes to object storage, so the log data itself is not tied to the node's disk.
- Volume ceiling: The documented limit is about 20 GB per day. Above that, plan for a different mode rather than tuning this one.
- Single process: One binary handles writes, reads and backend work, which simplifies upgrades and troubleshooting.
- Object storage still required: Compressed chunks and the index sit in object storage, so plan the bucket, credentials and lifecycle rules from the start.
- Authentication is your job: Loki has no built-in authentication layer, so an authenticating reverse proxy must sit in front of it.
- Production store choice: The docs recommend Amazon S3, Google Cloud Storage or Azure Blob Storage for production, and note that MinIO and the local filesystem are not typically recommended there.
Before committing, measure your actual daily ingestion across all sources and ask DeployOpen or Grafana Labs to confirm the mode for that figure, including growth over your planned retention window.
Simple scalable mode splits Loki into separate read, write and backend targets, and the Loki documentation places it in the range approaching 1 TB per day. It is a middle option for teams whose volume has outgrown a single process but who do not want a full microservices layout. The documentation states that this mode is being deprecated and will be removed with the Loki 4.0 release, so it is a poor base for a long-lived design.
- Volume range: The docs place this mode approaching 1 TB per day, between monolithic and microservices.
- Deprecation timing: Simple scalable mode will be removed in Loki 4.0, so a deployment built on it will need a migration plan.
- Independent scaling: Read and write paths can scale separately, which helps when query load and ingestion peak at different times.
- Shared object storage: All targets depend on the same bucket, so storage availability and access policy are shared failure points.
- Planning for migration: If you adopt it now, budget time for moving to a supported mode before the removal, and confirm the migration path with Grafana Labs.
Confirm with Grafana Labs which mode is recommended for your volume on the Loki version you intend to run, and ask how the 4.0 removal affects existing installs.
Microservices mode runs each Loki component as its own deployment, and the documentation aims it at very large clusters. It gives the finest control over scaling and failure isolation, but it moves the work into Kubernetes operations. This is the mode where platform engineering skill, cluster capacity and observability of Loki itself matter most, because each component has its own scaling, configuration and failure behavior.
- Intended scale: The docs position this mode for very large clusters, not for teams starting small.
- Kubernetes dependency: Expect to run and maintain the cluster, the Helm or manifest configuration and the upgrade path across many components.
- Component-level tuning: Ingesters, queriers and other components scale on different signals, which needs dashboards and runbooks.
- Shipper integration: Grafana Alloy, Fluent Bit, Fluentd and OpenTelemetry logs over HTTP all send to the same gateway path, so decide the ingestion entry point early.
- Team skill requirement: The staffing for this mode is usually the largest cost component, and it recurs with every upgrade.
Ask DeployOpen for a written scope that lists the components, the Kubernetes layout, the object store and the on-call responsibilities before choosing this mode.
OpenSearch documents Docker, Helm and the OpenSearch Kubernetes Operator as its container-based install methods. These suit teams that already run images and clusters, and they let the node layout, persistent volumes and rolling upgrades follow your platform standards. The OpenSearch install documentation covers these paths alongside the non-container methods, so the choice depends on how your platform team already manages workloads.
- Docker: Useful for development, test and small single-node environments where you want a fast, repeatable start.
- Helm chart: Fits teams that manage configuration as values files and deploy through a standard release pipeline.
- Kubernetes Operator: Fits teams that want the cluster lifecycle handled through custom resources, with the operator carrying more of the day-two work.
- Storage and node layout: Shard sizing, persistent volumes and node roles need design before the first deployment, whichever method you pick.
- Upgrade path: Confirm how each method handles rolling upgrades for the OpenSearch version your security team has approved.
Check which method your platform team already supports, and ask the vendor or DeployOpen to confirm how the chosen method handles your expected shard count and retention.
OpenSearch also installs from a tarball, RPM and Debian packages, through an Ansible playbook, and on Windows. These paths matter for virtual machines, bare metal and networks where container registries are restricted or where change control favors packaged software. They give direct control of the host, the service unit and the file layout, which helps when a team must reproduce a build exactly across air-gapped sites.
- Tarball: Gives the most direct control over file locations and is useful when you must stage an exact build offline.
- RPM and Debian packages: Fit distributions with established package management, patch windows and internal mirrors.
- Ansible playbook: Useful when many nodes need the same configuration and you want the setup captured as code.
- Windows: Documented as an install option, but confirm that it fits your security and operating baseline before you plan around it.
- Offline staging: Mirror the packages, plugins and security configuration into the enclave, and record the exact version used.
Before choosing, ask DeployOpen to confirm which package and playbook versions match your target OpenSearch release, and confirm the Security plugin setup on each host.
Side-by-side capabilities: indexing, query, identity and retention
This table compares how Grafana Loki and OpenSearch index, query, authenticate, control access to, and retain log data. Read each row as a question to answer for your own log sources, since the gap between a built-in control and one you must add in front of the store often decides the design.
| Capability | Grafana Loki | OpenSearch |
|---|---|---|
| Indexing model | Indexes only labels for each log stream; log contents are stored as compressed chunks in object storage | Builds an inverted index for full-text search; each shard is a full Lucene index |
| Query language and full-text search | LogQL filters by labels first, then scans matching chunks for text; confirm the performance of unindexed text searches on your data | Full-text search over indexed fields with its own query APIs; confirm the query languages and dashboard tooling your analysts already use |
| Multi-tenancy | Enabled with auth_enabled; tenants are identified by the X-Scope-OrgID header on every request | Tenant isolation is handled by the Security plugin's roles and access controls; confirm the tenancy model that fits your team boundaries |
| Built-in authentication | No built-in authentication layer; an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front | Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token backends |
| Document and field-level security | Not documented as a Loki feature; confirm whether your access rules can be enforced at the proxy or tenant level only | Document-level and field-level security, plus field masking and user impersonation |
| Audit logs and TLS | Confirm how audit trails of queries and access are produced at the proxy layer; TLS termination is typically handled in front of Loki | Audit logs and TLS for node and client traffic are part of the Security plugin |
| Retention controls | Applied by the compactor and disabled by default, so logs are kept until retention_enabled is set; rules can be global, per tenant or per stream selector, each at least 24 hours | Retention is managed through index lifecycle and data management features; confirm the policies your version supports |
| Shipper compatibility | Grafana Alloy is Grafana's supported shipper; also accepts OpenTelemetry logs over HTTP, Fluent Bit, Fluentd and the Docker logging driver | Confirm which shippers and ingest pipelines your existing agents support before committing to a migration path |
| Licensing of the security features | AGPL-3.0 for the core project; confirm which access-control features you need from the open-source build before planning | Apache-2.0 for all project software, and the FAQ describes no paid edition; confirm the feature set for your version |
What AGPLv3 and Apache-2.0 mean for each platform
Grafana Loki is licensed under AGPLv3. Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from the Apache License 2.0 to AGPLv3, so any Loki release you evaluate today is under AGPLv3 rather than the Apache terms that older community discussions often describe. Teams that adopted Loki before that date, or that copy older material into internal documentation, should confirm which license applies to the exact version they run.
- Announcement date: The license change was announced on April 20, 2021, according to the Grafana Labs licensing page.
- Current license: Grafana Loki is AGPLv3 licensed, according to the Loki documentation and GitHub repository.
- Version record: Check the license file in the specific tag you deploy, not only the main branch.
- Vendor position: Grafana Labs publishes its licensing terms on its licensing page, which is the place to confirm how the company treats its other core projects.
- Internal records: Update architecture decision records that still describe Loki as Apache-2.0.
Confirm the license of the exact Loki version and build you will run, and record that version in your third-party software inventory.
The AGPL extends the copyleft obligations of the GPL to software accessed over a network. In general terms, if you modify AGPL-licensed code and users interact with that modified code over a network, the license can require you to offer those users the corresponding source of your modifications. Whether this matters depends on whether you change Loki's code at all. Running unmodified upstream binaries for internal log storage is a different position from patching the query path, adding a custom plugin, or building a product on top of Loki that your customers reach over a network.
- Unmodified use: Running upstream Loki without changes is generally a simpler position, but confirm this with counsel for your own deployment pattern.
- Modified and network-served: Patches to Loki that users reach through a service boundary can trigger source offer obligations.
- Wrappers and configuration: Reverse proxies, dashboards and configuration management around Loki are separate programs, and their licenses need their own review.
- Internal versus external users: Whether users are employees or outside parties changes how exposure is judged, so record the audience for each deployment.
- Legal review: Ask counsel to review your modification policy and any custom Loki builds before production use.
Ask your legal team to write down which Loki changes, if any, your organization plans to make and who will interact with them.
All software in the OpenSearch project is released under the Apache License, Version 2.0. The OpenSearch FAQ does not describe any paid edition of the software. Apache-2.0 is a permissive license: it allows you to use, modify and redistribute the code, and it does not impose the AGPL network source offer obligation. That does not remove the need for review, since patent terms, notice requirements and third-party components in the distribution still apply, and the FAQ statement describes the project, not every add-on or hosted service a vendor may sell.
- License scope: All software in the OpenSearch project is Apache-2.0, according to the OpenSearch FAQ.
- No paid edition described: The FAQ does not describe a paid edition, so ask any vendor offering support or add-ons to name the exact software they cover.
- Foundation governance: The OpenSearch Software Foundation is a Linux Foundation project, and it does not oversee the technical direction of OpenSearch.
- Notices and attribution: Apache-2.0 requires license and notice retention when you redistribute, so track these in your build pipeline.
- Plugins: Confirm the license of any OpenSearch plugin or dashboard component you add.
Confirm the license of every OpenSearch component in your build, including plugins and Dashboards, against the project's own license files.
Grafana Enterprise Logs (GEL) is a separate product from open source Loki, and the Loki documentation points to its own Enterprise Logs documentation. The supplied facts do not describe GEL's license, feature set or commercial terms, so this page does not assume what it adds. If your team considers GEL, it is a different procurement with different terms, and the AGPL analysis for open source Loki does not automatically transfer to it.
- Separate product: Grafana Enterprise Logs is documented separately from open source Loki, according to the Grafana Enterprise Logs documentation.
- No inferred features: Do not assume GEL includes or excludes any capability of Loki unless the vendor confirms it in writing.
- Separate license: Ask Grafana Labs for the license terms that apply to GEL and to any binaries or support it includes.
- Mixed estates: If you run both products, track each component's license separately in your inventory.
- Procurement scope: Ask for the product scope, support terms and license text in the quote before comparing costs.
Ask Grafana Labs for the written license and product scope of Enterprise Logs before you treat it as a substitute for open source Loki in this comparison.
What drives log storage cost on Loki and OpenSearch
Loki cost follows the volume of compressed chunks you keep in object storage, not the volume of text you index. Loki indexes only labels for each log stream, so the index stays small as long as label cardinality stays under control. The costs that move are the bytes written as compressed chunks, the object storage pricing your provider charges for those bytes and their requests, and how long you keep them. Retention is disabled by default, which means logs are kept indefinitely until you set retention_enabled and define rules for the compactor. Each stream rule must cover at least 24 hours, so review retention per tenant and per stream selector before go-live rather than after the bucket grows. High label cardinality, such as request IDs or user IDs used as labels, multiplies stream count and inflates the index and ingester memory, so it is the most common hidden cost driver. Confirm your object store's pricing model and your provider's request charges with the vendor, since Loki's own documentation does not set them for you.
OpenSearch cost follows the size of its full-text inverted indexes and how those indexes are laid out across nodes. Each index is split into shards, and each shard is a full Lucene index, so shard count, replica count and node disk all multiply the stored footprint. Adding a replica roughly doubles the storage each copy occupies, and oversharding small indexes adds overhead without adding capacity. Index lifecycle policies and the number of hot, warm or cold tiers you run determine how much of that footprint stays on expensive local disk. Ask your implementer to model shard sizing and replica counts against your daily ingest and retention window before you size nodes, and confirm current storage and support terms with the vendor or your partner in a written quote.
What you give up on Loki is the ability to search log contents cheaply. Because log text is not indexed, queries that filter on words inside a message must scan the matching chunks, which is slower and more expensive to run at scale. Field extraction and pattern filters happen at query time, so security teams hunting for an arbitrary string across weeks of data should test LogQL against a realistic sample before committing. If your use case is ad hoc investigation across unstructured fields, the storage saving on Loki comes with a query-time cost you must plan for and measure.
What drives running cost for each platform
Running cost for Loki and OpenSearch comes from different places: object storage and compute for Loki, data nodes and storage for OpenSearch. The cards below cover where that money goes, the skills each team needs, what vendor support looks like, how upgrades differ, and what to put in a quote so the figures can be compared.
Infrastructure footprint for Loki
Loki keeps compressed log chunks and its index in object storage, so the main recurring line is the object store bill plus the compute that runs the write, read and backend paths. Ingest volume, label cardinality and query load move both lines. Ask the quote to price object storage requests and egress separately from compute, and to state which deployment mode it assumes. The Loki storage documentation lists Amazon S3, Google Cloud Storage and Azure Blob Storage as recommended production stores, and MinIO and local filesystems as supported but not typically recommended for production.
Infrastructure footprint for OpenSearch
OpenSearch cost sits in data nodes, master nodes and the storage attached to them, because each shard is a full Lucene index that must live on fast disk to stay queryable. Replica count, shard sizing and retention multiply disk and memory needs. Ask the quote to show node counts by role, disk per node, replica settings and the retention period behind the sizing. A cluster sized for a security analytics workload usually costs more per retained day than an object-store-backed design, so compare on the same retention and query window.
Skills and day-two operations
Loki teams need LogQL, label design discipline and object store operations, including lifecycle rules, credentials and retention enforcement through the compactor. OpenSearch teams need Lucene-level tuning, shard and index lifecycle management, heap sizing and cluster recovery skills. Both platforms need someone who owns retention and access policy. Ask the quote to name which roles are assumed, whether DeployOpen or the client team runs routine operations, and how many hours of operator time the retainer covers. Training and hiring costs are rarely in the initial quote.
Vendor and community support options
Both products are Apache-licensed open source, and the OpenSearch FAQ does not describe any paid edition, so vendor support is a separate choice. Grafana Labs offers Grafana Enterprise Logs as a commercial alternative to open source Loki, and OpenSearch support typically comes from a service provider or the client's own staff. Ask each candidate which support tier is included, the response model, and whether the quote covers security patch turnaround. Confirm these terms with the vendor, since they are not part of the supplied research.
Upgrade effort and maintenance windows
OpenSearch targets a new minor version about every eight weeks, and each version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance it receives bug and security fixes but no new features, so budget regular minor upgrades on a schedule. Loki's simple scalable deployment mode is being deprecated and will be removed in Loki 4.0, so teams on that mode must plan a move to monolithic or microservices. Ask the quote to include both upgrade paths and the testing effort for each.
What to ask for in a quote
Ask for a written scope that separates one-time work (design, deployment, integration, hardening, documentation) from recurring work (retainers, upgrades, monitoring, backups and continuous testing). Request the daily ingest volume, retention per stream, expected query load and the object store or disk sizing assumed for each option. Compare both quotes on the same retention window and the same query window, and ask who pays for cloud egress and licensing. DeployOpen does not publish a price list, so the written scope is the basis for any figure.
How to move logs from one platform to the other
The sequence runs both stores in parallel, dual-ships logs, rebuilds queries and alerts, carries retention over as policy, and retires the old store only after the new one has been verified. Logs themselves move by re-ingestion rather than by index conversion.
Run both stores in parallel
Stand up Loki and OpenSearch side by side on separate infrastructure, using the deployment mode that matches your expected volume. Your platform or SRE team owns the build, and DeployOpen can provide this as a scoped implementation if you choose. The step is done when both stores accept test writes, answer test queries, and sit behind the same authentication path you will use in production. Confirm the Loki object store and OpenSearch storage sizing with the vendor documentation and your own volume data, since no sizing figures apply to your environment.
Dual-ship logs to both platforms
Configure your shipper to send each log stream to both destinations. Grafana Alloy, Fluent Bit, Fluentd or the OpenTelemetry Collector can fan out one pipeline to two outputs, and Loki also accepts OpenTelemetry logs over HTTP. Keep labels for Loki deliberately small, because each stream is defined by its labels, while OpenSearch needs index templates and field mappings that match the parsed fields. The step is done when a sample of production events appears in both stores with matching timestamps and counts within the tolerance your audit team accepts.
Map queries and rebuild dashboards
Translate each saved query and dashboard panel by intent rather than by syntax. A LogQL stream selector with a line filter becomes an OpenSearch query on indexed fields, and aggregations over parsed labels become OpenSearch aggregations or PPL-style queries where that language fits. Loki answers unlabeled full-text searches by scanning chunks, so some OpenSearch searches will be slower or need a different design in Loki. Dashboard owners and detection engineers do this work with the query reference for each product. The step is done when each dashboard panel has a documented equivalent and a reviewer has confirmed the results on the same time window.
Rebuild alerts and detection rules
Recreate each alert and detection rule in the target platform's rule format, since alerting definitions do not carry over between Loki and OpenSearch. Security analytics teams should pay particular attention to rules that depend on full-text matching or on fields that Loki would store only as unindexed content. Run each rebuilt rule against replayed or dual-shipped events and record whether it fires on the same known cases. The step is done when every rule in the inventory has a tested equivalent or a documented decision to retire it.
Migrate retention policies as configuration
Translate retention targets into each platform's settings. Loki retention is applied by the compactor and stays disabled until retention_enabled is set, and it can be global, per tenant or per stream selector, with each stream rule at least 24 hours. OpenSearch retention is typically handled through index lifecycle policies and rollover. Compliance and records owners should sign off the new values before the old store is retired. The step is done when retention settings in both platforms match the approved schedule and a test deletion or expiry has been observed in each.
Re-ingest history if it must be kept
Plan what happens to historical logs. Raw logs can move only by re-ingesting them through a shipper, because OpenSearch's ability to read Elasticsearch 6.0 to 7.10 indices does not extend to Loki, and Loki has no equivalent index migration path. Export archived raw files from the old store where your retention rules allow, then replay them through the new pipeline with correct timestamps. Confirm with your legal and compliance owners which history must be preserved and in what form. The step is done when the replay log shows a count and time range that match the source archive.
Cut over and verify access controls
Point analysts, dashboards and alert routing at the new platform, and confirm access controls before users rely on it. Loki's multi-tenant mode depends on auth_enabled and the X-Scope-OrgID header, and it has no built-in authentication layer, so an authenticating reverse proxy must sit in front of it. OpenSearch's Security plugin provides its own role-based controls and audit logs, which you should map to your existing groups. The step is done when a test of each role confirms the expected access and audit entries appear.
Retire the old store with evidence
After a parallel run that your operations and security owners accept, stop dual-shipping, keep the old store read-only for the agreed period, and then decommission it. Record the final configuration, the comparison results and the retention actions in your change records. Your compliance lead should confirm the archive location and access process before the old data is deleted. The step is done when the old store is decommissioned, the evidence package is filed, and no pipeline still writes to it.
Where Loki and OpenSearch implementations usually run long
Loki projects tend to run long on the parts around the binary: the object store, the authentication layer, tenant design, retention and the shipper pipeline. Loki has no built-in authentication layer, so the documentation requires an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Teams that plan for a single HTTP endpoint often discover late that X-Scope-OrgID tenant headers, the reverse proxy's identity mapping and the auth_enabled setting must agree before any tenant is onboarded. Retention is the other common surprise. Retention is disabled by default, so logs are kept indefinitely until retention_enabled is set and the compactor is configured, and each stream rule must be at least 24 hours. Confirm the object store choice early: the docs name S3, Google Cloud Storage and Azure Blob Storage as recommended production stores, and note that S3-compatible stores and local filesystems are not typically recommended for production. Shipper configuration (Grafana Alloy, Fluent Bit, Fluentd or OpenTelemetry) then adds label design work, since labels are the only index.
OpenSearch projects tend to run long on cluster sizing, Security plugin configuration, index lifecycle and upgrade planning. Sizing is driven by shard layout, because each shard is a full Lucene index and the shard count set at index creation shapes both query cost and recovery time. Index lifecycle decisions (rollover, retention and deletion policies per data stream) need named owners, because they determine what storage is paid for after the first month. The Security plugin brings SAML, OpenID Connect, Active Directory or LDAP, Kerberos and JSON Web Token backends, plus role-based access control, document- and field-level security, field masking and audit logs, and each of these needs roles mapped to the identity provider's groups before analysts can search. Upgrade planning is a recurring cost: OpenSearch 3.9.0 followed 3.8.0 by about eight weeks, and versions in maintenance receive security fixes but no new features, so the client should schedule minor upgrades rather than defer them.
Projects usually overrun when the client has not supplied its inputs on time. Before scoping, the client should provide an identity provider with group claims for both platforms, network paths and firewall rules between log sources, reverse proxies or cluster nodes, and the object store or disk capacity to hold the planned retention. They should also name owners for tenant onboarding, retention approval, index lifecycle and upgrade windows, and confirm who holds the on-call duty for ingestion failures. A useful first step is a written list of log sources, daily volume estimates, required search patterns and retention periods per source, so the implementation can be sized and fixed in scope. Treat any volume or sizing figure as something to measure in the client's own environment, because the Loki deployment mode guidance and OpenSearch sizing depend on actual ingestion.
Questions buyers ask before choosing Loki or OpenSearch
What does the implementation effort for Loki or OpenSearch actually depend on?
The effort depends mostly on daily log volume, retention length, query patterns and how many teams send logs. Loki's effort centers on object storage, the chosen deployment mode and the authenticating reverse proxy it requires, since Loki has no built-in authentication layer. OpenSearch's effort centers on cluster sizing, shard layout, index lifecycle policies and the Security plugin configuration. Ask any implementation partner to list the volume, retention, number of sources and identity requirements they assumed, and to show how each one changes the scope.
Can our team run Loki or OpenSearch ourselves without outside help?
A team with Linux, object storage and Kubernetes or VM operations experience can run either platform, but the work is ongoing rather than a one-time install. Loki needs you to manage the compactor, retention settings, tenant headers and the reverse proxy in front of it. OpenSearch needs you to manage node roles, shard counts, snapshots, security configuration and version upgrades, with maintenance releases arriving roughly every eight weeks for new minor versions. Be honest about who on the team will carry each of these tasks after go-live.
How long does a typical rollout take?
Rollout length is driven by the number of log sources, the identity integration, the retention and compliance requirements, and how much dashboard and alert migration is involved. Loki projects often move quickly on the storage side but spend time on shipper configuration and tenant design. OpenSearch projects often spend more time on index design, security roles and dashboards. DeployOpen scopes each engagement in writing before work starts, so ask for the timeline as a list of milestones tied to those drivers rather than a single number.
Can Loki do full-text search across log contents?
Loki does not index log contents. It indexes only labels for each log stream and stores compressed chunks in object storage, so you narrow results with label selectors and then filter the text in the chunks. That works well for troubleshooting by service, namespace or host. It is slower for hunting an unknown string across all history, and it is a weaker fit for security analytics that depend on arbitrary field searches. If you need fast free-text search over everything, test OpenSearch against a sample of your real queries before deciding.
How does the AGPL license affect internal use of Loki?
Grafana Labs moved Loki from Apache License 2.0 to AGPLv3 on April 20, 2021. The AGPL obligations apply when you distribute modified versions or offer them to users over a network, so running Loki internally for your own staff generally does not trigger source disclosure of your own applications. Whether a specific use creates an obligation is a legal question. Have your counsel review the deployment, especially if you modify Loki or expose it to customers, partners or a public service. OpenSearch is Apache-2.0, which many legal teams find simpler.
What does OpenSearch Security need before it is production ready?
Before go-live, OpenSearch Security needs an agreed authentication backend, such as SAML, OpenID Connect, Active Directory, LDAP, Kerberos or JSON Web Token, plus role mappings that reflect who may read which indexes. You also need TLS for node and client traffic, audit logging turned on with an agreed destination, and decisions on document-level, field-level and field masking rules for sensitive data. Ask the implementer to document each role, test it with real user groups, and show how changes are reviewed and recorded.
What should we ask for in a fixed-scope quote?
Ask for a written scope that lists the platform version, deployment method, number of log sources and daily volume assumed, retention periods, identity integration, dashboards and alerts to migrate, backup and restore tests, and documentation handover. Ask which items are one-time work and which are recurring, such as retainer support, upgrades and continuous testing. DeployOpen does not publish a price list, so the quote follows from that written scope. Also ask what changes the scope and how additional work is agreed before it starts.
How DeployOpen helps you choose and implement a log platform
DeployOpen helps teams decide between Loki and OpenSearch by first mapping their query patterns, retention needs and security analytics requirements to each platform's architecture. We then plan, build and hand over the chosen platform inside your own cloud accounts, data centers or air-gapped networks.
How we scope
- We document which queries your analysts run most, such as label-based stream lookups versus full-text search across message bodies.
- We size log volume, retention periods and expected index growth so the written scope reflects your actual storage and query needs.
- Engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before any work starts.
How we build
- We deploy the selected platform in your environment, choosing a deployment mode that matches your daily volume and HA requirements.
- We configure object storage, retention, tenant isolation or authentication, and the log shippers that feed your sources.
- We run security testing and hardening on the deployed stack, then prepare configuration and evidence for your compliance assessments.
How we hand over
- We document architecture, configuration, retention rules and runbooks so your team can operate the platform without us.
- We walk your engineers through query patterns, alerting paths and backup and restore procedures on your own systems.
- We confirm licensing terms, edition boundaries and upgrade paths with you in writing so your team knows what it owns.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer covering your chosen log platform.
- We plan version upgrades against each project's published maintenance windows and test them before they reach production.
- We can extend the platform as sources, retention or compliance requirements change, with each change scoped in writing first.
