Loki vs Elasticsearch: which to choose

Loki vs Elasticsearch: when each one fits

Choose Grafana Loki when your logs are mostly queried by known labels such as service, environment, namespace or host, and you want the index kept small while compressed chunks sit in object storage. Choose Elasticsearch when analysts need arbitrary full-text search across message bodies, fast ad hoc investigation over unstructured fields, or the broader search and analytics features that come with the Elastic stack. Neither answer is universal, so the decision should be tested against your own log content rather than a vendor summary.

Four factors drive the choice. The first is query pattern: Loki's LogQL performs best when a query narrows to a label set before scanning content, while Elasticsearch's inverted index answers content searches directly. The second is volume and retention. Loki's monolithic mode is documented for up to about 20 GB of logs per day and simple scalable mode for approaching 1 TB per day, and its retention is disabled by default, so you must set it deliberately. The third is the license you accept. Loki is AGPLv3. Elasticsearch source is available under the Elastic License 2.0, SSPL 1.0 or AGPLv3, and only AGPLv3 is OSI-approved, so legal review should cover the license you actually select, not the product name. The fourth is who operates it. Loki's microservices mode on Kubernetes and Elasticsearch's three-master-node minimum for a highly available cluster both add operating work that should be sized before procurement.

Before you commit, confirm three things with your own data: the share of queries that filter on content rather than labels, the daily ingest and retention period you need, and which security features you require, because Elastic places some of them in paid tiers and Loki has no built-in authentication layer and needs an authenticating reverse proxy in front of it. Pilot both with a representative sample so the cost and effort figures come from your environment, not from assumptions.

Which scenarios favor Loki and which favor Elasticsearch

This table maps common logging workloads to the platform that usually fits them better and gives the reason for each choice. Read each row as a default, since the fit depends on your query patterns and the tooling your team already runs.

Scenario	Better fit	Reason and what to confirm
Mostly known-label troubleshooting with Grafana dashboards	Loki	Loki indexes only stream labels such as service and environment, so label-filtered queries in Grafana run against the known streams. Confirm that your labels stay low cardinality.
Free-text investigation across unknown fields	Elasticsearch	Elasticsearch builds an inverted index over log contents, so ad hoc searches on arbitrary terms are its strength. Loki must scan matching chunks for text that is not in a label.
Security analytics and detection content	Elasticsearch	Full-text and field-level search across many sources, plus the Elastic security features, suit SOC workflows. Confirm which detection features your license tier includes before relying on them.
Long retention on object storage	Loki	Loki keeps compressed chunks and its index in object storage such as S3, and retention is set by the compactor. Retention is disabled by default, so you must enable it deliberately.
Teams already running Elastic for SIEM	Elasticsearch	Reusing existing clusters, agents, rules and staff skills usually lowers effort more than the storage model does. Confirm whether the SIEM workload justifies a shared cluster.
Teams already running Grafana and Prometheus	Loki	Grafana, Alloy and LogQL share one operating model and query experience with metrics, which reduces tooling to learn. Confirm that your shipper and dashboard templates match.
Compliance evidence that depends on authentication and access control in the log store	Elasticsearch	Elasticsearch includes role-based access control and SSO in its tiers, while Loki has no built-in authentication and requires an authenticating reverse proxy. Confirm the controls each option needs for your assessment.

How Loki and Elasticsearch are built and what that means for operations

Loki and Elasticsearch make different bets about where log data is indexed and where it lives. Those bets decide which components you run, how you size storage and how much cluster management your team inherits. The cards below tie each design choice to the work it creates after go-live.

Label-only indexing in Loki

Loki indexes only the labels attached to each log stream, not the text of the log lines. Queries narrow down by label first, then scan the matching compressed chunks. This keeps the index small, but it means high-cardinality values such as request IDs belong in the log body, not in labels. Check your label design early, because changing labels later affects how streams are split and queried. Confirm which index store your Loki version uses, since the storage documentation recommends TSDB for Loki 2.8 and newer.

Compressed chunks in object storage

Loki keeps compressed log chunks and its index in object storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage. Your team runs the object store, its access policies, lifecycle settings and backups, not a cluster of data nodes. The documentation notes that S3-compatible stores and the local filesystem are supported but not typically recommended for production. Retention is also your job: the compactor only deletes data once retention is enabled, so logs are kept indefinitely by default.

Loki deployment modes and the 4.0 change

Loki offers monolithic mode for a single binary, simple scalable mode with separate read, write and backend targets, and microservices mode for very large clusters. Simple scalable mode is being deprecated and will be removed with Loki 4.0, so a new build on it will need a migration plan. Monolithic mode suits smaller volumes, while microservices mode brings the most components to run on Kubernetes. Confirm the daily volume you expect against the sizing guidance before picking a mode.

Inverted index and Lucene shards

Elasticsearch builds an inverted index over the content of documents, which makes full-text and field-level search fast across all log text. Each index is split into shards, and each shard is a full Lucene index with its own storage and memory footprint. Shard count and size are the decisions that most affect performance and recovery time. Ask your vendor or partner to show a sizing model for your daily volume and retention before committing to a shard layout.

Node roles and tiers

Elasticsearch separates work across node roles: master-eligible, data (with hot, warm, cold and frozen tiers), ingest, machine learning, transform, remote cluster client and coordinating-only. Each role can run on a dedicated node, so the operator decides how to lay out the cluster and which tiers hold recent versus archived logs. Role layout drives hardware, placement and upgrade order. Review the node roles documentation for your target version before writing a topology.

Three master-eligible nodes minimum

A highly available Elasticsearch cluster needs at least three master-eligible nodes so it can keep a quorum when one fails. Two nodes cannot tolerate a failure without risking split decisions about cluster state. Your team must monitor these nodes, patch them in rolling order and test failover before relying on it for security logs. Loki has no equivalent cluster quorum to run, but it does need its object store and reverse proxy to be highly available in their own right.

Indexing, query, retention and access control compared

This table compares how Grafana Loki and Elasticsearch index logs, query them, keep them and control access. Read each row as a question to answer for your own log estate, then check the items marked for confirmation against current documentation and your own tests.

Capability	Grafana Loki	Elasticsearch
Indexing model	Indexes only labels for each log stream, not log contents, so the index stays small relative to the logs	Builds an inverted full-text index over fields, with data split into shards that are each a Lucene index
Query language and capability	LogQL filters by labels first, then scans matching chunks for text; best when queries start from known stream labels	Full-text search and aggregations across any indexed field; suits ad hoc investigation across arbitrary terms
Storage design	Compressed chunks and index in object storage such as S3; Amazon S3, Google Cloud Storage and Azure Blob are the recommended production stores	Indexes and data live on node-local or attached storage in a cluster; tiering to hot, warm, cold and frozen data roles is configured per node
Retention controls	Retention is disabled by default, so logs persist until retention is enabled; can be set globally, per tenant or per stream selector with a 24-hour minimum per rule	Retention is set through index lifecycle policies; confirm the exact lifecycle options and tier behavior for your license tier
Multi-tenancy	Enabled when auth_enabled is true; tenants are identified by the X-Scope-OrgID header on every request	Separation is handled through spaces, roles and index permissions; confirm the isolation model your use case needs
Built-in authentication	No built-in authentication layer; you must place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it	Built-in native users and realms; TLS, the file and native realms and role-based access control are available in the free Basic tier
Single sign-on and directory login	Depends on the reverse proxy you put in front of Loki; plan and test the identity integration yourself	SAML, OpenID Connect, Kerberos and JWT single sign-on, plus Active Directory and LDAP authentication, sit in paid tiers
Field and document-level security	Not a Loki feature; tenant separation and proxy rules are the controls to design and test	Field- and document-level security is a paid feature; confirm the tier that includes it before relying on it
Licensing of security features	Core product is AGPLv3; access controls come from your own proxy stack and your team's configuration	Elastic License 2.0 is the default distribution; security features are free in Basic, with SSO and field-level security in paid tiers

What the AGPLv3, Elastic License 2.0 and SSPL terms mean for you

Grafana Loki is licensed under AGPLv3. Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from Apache License 2.0 to AGPLv3, so any Loki build you adopt from that point on carries the copyleft terms rather than the permissive ones. The AGPL is an OSI-approved open source license, and it is the same family of terms that governs Zabbix and MinIO in this pillar, which makes it a familiar category for many legal teams.

Internal use: Running Loki inside your own organization for your own log analytics is the simplest case, and the license does not require you to publish your logs or configuration.
Modified code: If you patch Loki and make the modified version available to users over a network, the AGPL's network clause may require you to offer those users the corresponding source of your changes.
Hosted service: Offering Loki-based logging to customers as a service is the scenario where the network clause matters most, and your counsel should read it against your exact delivery model.
Apache-2.0 history: Versions distributed before the 2021 change were under Apache License 2.0, so the license of any copy you hold depends on the version you installed.
Authentication layer: Loki has no built-in authentication, so you will run an authenticating reverse proxy in front of it. That proxy carries its own license, which you should check separately.

Confirm with counsel which Loki version and build your team will deploy, and whether any internal modifications would trigger the network obligation.

Where log storage cost really goes

The largest recurring cost in either platform is usually the storage and compute needed to keep logs searchable for the retention period your auditors and incident responders require. In Loki, retention length and stream cardinality set most of the bill. Loki stores compressed chunks in object storage such as S3, so the storage line is mostly object capacity multiplied by retention. Label cardinality matters because every distinct label combination creates a new stream, which adds index entries and small chunks that cost more to write and query. Retention is disabled by default in Loki, so logs accumulate indefinitely until retention_enabled is set on the compactor. Confirm your retention targets per tenant or per stream selector before you size anything.

In Elasticsearch, the recurring cost sits in shard disks, replicas and the node count needed to keep hot data fast. Each index is split into shards that are full Lucene indexes, and replicas multiply that footprint. Field count and high-cardinality fields increase the inverted index size, so the cost of extra fields is paid on every node that holds a shard. Node roles also matter: a highly available cluster needs at least three master-eligible nodes, and hot, warm, cold and frozen data tiers let you move older indexes to cheaper hardware. Ask the vendor or your partner to model shard count, replica count and tier placement against your daily volume and retention, not just total terabytes.

Staff time and one-time work often outweigh infrastructure in the first year. Migration covers dashboards, alerts, log shippers and parsing pipelines, so budget for rebuilding Kibana or Grafana content and re-testing ingest paths, whichever direction you move. Recurring effort includes version upgrades (Elastic publishes end-of-maintenance dates for each major line, so confirm where your version sits on the Elastic product end of life dates page), operating the object store or the cluster, and licensing or support decisions. Ask for a written estimate that separates one-time migration from monthly run cost and states which upgrades and tier features are included. The quote should show who operates storage, who handles on-call for ingest failures and what happens when retention grows faster than forecast.

What drives running cost for each platform

Running cost for either platform is mostly staff time, storage and upgrade work rather than license fees, since both are open source. The cards below separate the drivers that raise cost from those that lower it, and name what to request in a quote before you commit to a design.

Infrastructure and storage footprint

Loki's main cost is object storage for compressed chunks, because its index covers only labels. Elasticsearch stores inverted indexes and shard data on nodes, so its cost tracks disk, memory and replica count. For each option, ask the vendor or partner to size ingest per day, retention per tier and replica count, then price the storage class and network egress in your own cloud account. Confirm whether your highest-volume streams are the ones you intend to search by full text.

Skills and operating staff

Elasticsearch clusters need people who understand shard sizing, index lifecycle policies, heap tuning and node roles, and a highly available cluster needs at least three master-eligible nodes. Loki shifts effort toward object store operations, the compactor, label design and reverse proxy authentication. Price the internal hours or retainer hours each option needs during the first year and during steady state, and state which skills your team already has.

Support and edition choices

Both platforms are free to run, but paid tiers change what you can operate. Elastic's self-managed page offers Free and open (Basic), Platinum and Enterprise tiers, and security features such as single sign-on, field- and document-level security and anomaly detection alerting sit in paid tiers. Loki has no built-in authentication layer, so you pay in engineering time for a reverse proxy, or in a commercial edition if you need access control. Ask each vendor which features are included at your tier and what support response terms apply.

Upgrade planning and end of maintenance

Elastic maintains each major release for a limited window, and the EOL page lists end of maintenance for the 8.x line on January 15, 2027 and for the 9.x line on October 15, 2027. Plan any Elasticsearch upgrade work against those dates, since a move from 8.x to 9.x carries its own testing and compatibility effort. Loki's release cadence should be confirmed against the Loki GitHub releases page before you set an upgrade calendar, and note that simple scalable mode is slated for removal in Loki 4.0.

Retention and query workload

Retention is where cost compounds. Loki keeps logs indefinitely until retention is enabled in the compactor, and retention can be set globally, per tenant or per stream selector, with each rule at least 24 hours. Elasticsearch costs rise with hot and warm tier size and with replicas. Ask for a retention table by log source and by tier, and test how often the team runs full-text searches over older data, because frequent searches over long history raise compute cost on both sides.

Quote and implementation scope

DeployOpen works from a fixed written scope, so ask any partner to separate one-time work (design, sizing, deployment, authentication integration, dashboards and migration of shippers) from recurring work (retainer support, upgrades and continuous testing). Request assumptions for daily ingest, retention, number of tenants, replica count and hardware or cloud sizing. A quote that does not state these assumptions cannot be compared fairly with another option.

How to move logs from Elasticsearch to Loki or back

This sequence moves log collection, dashboards, alerts and access from one stack to the other without losing visibility during the switch. It ends with a cutover that has been checked against both systems running side by side.

Inventory log sources, fields and consumers
The platform team lists every source shipping to Elasticsearch today, including the fields each index relies on, the indices and data streams in use, and the teams that query them. Security analysts usually need the full-text search and field-level detail that drives the rest of the design, so they should review the inventory too. The step closes when every source has an owner and every field a dashboard or alert depends on is written down. Confirm the current Elasticsearch version and its support status against the Elastic end-of-life page before deciding how much history matters.
Design labels and rebuild shippers
Because Loki indexes only labels, the team chooses a small, stable set of low-cardinality labels such as application, environment and namespace, and keeps message content in the log line. Shippers are rebuilt for this model, typically with Grafana Alloy, which Grafana supports for Loki, or with another supported client such as Fluent Bit. Elasticsearch-specific pipelines such as Logstash or Beats configurations are translated, not copied. The step closes when a test source sends logs with the agreed labels and a sample of queries returns the expected streams. Check high-cardinality fields such as request IDs before they become labels, because they inflate the index.
Run both systems in parallel
New sources are sent to Loki while the existing Elasticsearch pipeline keeps running, so both systems receive the same events for a period agreed by the team. Operators compare event counts, parse results and timestamps between the two stores for each source. Gaps and parse differences are fixed in the shipper configuration before anything else moves. The step closes when each source shows matching volumes and fields in both systems. Keep the parallel period under review, since running two log stacks has its own cost in compute, storage and staff attention.
Rewrite dashboards and alerts in LogQL
Kibana dashboards and saved searches are rebuilt as Grafana dashboards that query Loki with LogQL, because Kibana objects do not import into Loki. Full-text Lucene or KQL queries are reworked around labels and line filters, and any query that depends on an unindexed field is redesigned or moved to a metrics query. Alert rules are recreated in the Loki ruler or Grafana alerting and tested against known incidents. The step closes when each dashboard and alert has a named owner and has fired or displayed expected results during the parallel run. Expect some Elasticsearch searches to have no direct LogQL equivalent, and record each of those as a decision for the owner.
Decide history to migrate or expire
Raw logs do not transfer between the two stores. Logs that must be queried later can only reach Loki by re-ingesting the original files or exports, which is a separate project with its own storage and time. For most teams the decision is to keep Elasticsearch read-only for a defined retention window, then let it expire, and migrate only history that legal, audit or incident teams need in searchable form. The step closes with a written retention decision per data class, approved by the owners of compliance and security. Retention in Loki is disabled by default and must be enabled deliberately, so confirm the retention rules before cutover.
Recreate access policies and tenancy
Access that Elasticsearch enforces through roles, spaces and field-level security must be rebuilt in the new stack. Loki has no built-in authentication layer, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium is placed in front of it, and multi-tenancy is enabled with the X-Scope-OrgID header where teams need separation. Grafana role mappings replace Kibana spaces. The step closes when test accounts confirm that each group sees only the sources and tenants it is approved for. Field-level restrictions that Elasticsearch provided may not have a direct equivalent in Loki, so confirm them with the security owner before cutover.
Cut over and retire the old pipeline
The team switches the remaining sources to Loki, points analysts and automated consumers to the new dashboards and alert endpoints, and stops the Elasticsearch ingest pipelines in a planned change window. Elasticsearch stays readable for the retention window decided earlier, then is decommissioned on the agreed schedule. The step closes when no source is writing to Elasticsearch, alert paths are confirmed end to end, and a rollback procedure has been tested. For a reverse move from Loki back to Elasticsearch, the same order applies, with the work moving to Elasticsearch mappings and Kibana objects instead.

What implementing each platform involves and where projects run long

Loki's setup effort sits mostly in the object store, the tenant boundary and the shipping pipeline. Loki keeps compressed chunks and its TSDB index in object storage, so the first decisions are the bucket layout, the lifecycle of the data and the credentials the ingesters and compactor use. Retention is off by default in Loki, so a team that does not set retention_enabled on the compactor keeps logs indefinitely, and the retention rules per tenant or per stream selector need to be written down before go-live. Loki also has no built-in authentication layer. Auth is enforced by an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium, which must set or validate the X-Scope-OrgID header when auth_enabled is true. Design that header mapping early, because clients that can forge it can read another tenant's logs. Confirm with your own proxy team how identity from your SSO provider reaches that header.

Elasticsearch's setup effort sits in cluster topology and security configuration. A highly available cluster needs at least three master-eligible nodes, and the data tiers (hot, warm, cold and frozen) and ingest nodes each need sizing against your daily volume and query pattern. Index lifecycle policies decide rollover, shrink, force-merge and deletion, and they are where storage cost is actually controlled. On the security side, TLS, the native and file realms and role-based access control are free in the Basic tier, but single sign-on through SAML, OpenID Connect or Kerberos, Active Directory and LDAP authentication, and field- or document-level security are paid features. Confirm which of these your environment needs against the current Elastic subscriptions page before writing the design.

Projects run long in four predictable places. First, label cardinality in Loki: a label such as a request ID or pod name created per stream multiplies the index and slows queries, and the fix is a label schema agreed with application teams before shippers go live. Second, unplanned query load: dashboards and alert rules that scan wide time ranges can starve ingestion on either platform, so set query limits and test with your heaviest real dashboards. Third, RBAC and SSO wiring, which usually takes longer than the cluster build because group mappings, tenant headers and role definitions must agree across the proxy, the identity provider and the log platform. Fourth, dashboard migration: Kibana saved objects and Grafana dashboards use different query languages and panel models, so every dashboard needs rewriting and validating against the new data. A fixed-scope agreement from DeployOpen would list the platform, the shipper count, the tenant and role model, the dashboards in scope and the test cases, and would name what the client provides, such as object storage, identity groups and sample log data. Timelines follow from that written scope.

Questions buyers ask before choosing between Loki and Elasticsearch

Which is cheaper to run at scale, Loki or Elasticsearch?

Loki is usually cheaper on storage for log volumes where most queries filter by a small set of labels, because it indexes only labels and keeps compressed chunks in object storage. Elasticsearch builds a full-text inverted index over log contents, so storage, memory and shard count grow with the data you index. Cost drivers include daily volume, retention length, label cardinality in Loki, query concurrency, replica counts and the object store you choose. For a quote, ask the vendor or partner to model your ingest rate, retention per stream, replica settings and query patterns for both platforms, and to state which hardware or cloud costs are included.

Is Loki's AGPL license a problem for internal use?

The AGPLv3 license that Grafana Labs applies to Loki, announced on April 20, 2021 as a move from Apache License 2.0, does not restrict running Loki inside your own organization. Its extra obligations apply when you modify Loki and make it available to users over a network, so you must offer those users the source of your changes. Ask your legal team to review whether any internal modifications or customer-facing services would trigger that duty. Elasticsearch is available under Elastic License 2.0, SSPL 1.0 and AGPLv3, and the default distribution is ELv2, which carries its own restrictions on offering it as a managed service.

Which Elasticsearch features require a paid subscription?

Elastic moved TLS, the file and native user realms and role-based access control into the free Basic tier with versions 6.8.0 and 7.1.0 on May 20, 2019. Single sign-on, Active Directory and LDAP authentication, and field- or document-level security stayed in paid tiers, and the self-managed subscriptions page lists those security features with the tiers that include them. Alerting rules based on anomaly detection are limited to Platinum and Enterprise, and Elastic states that Platinum is no longer offered to new customers. Confirm the current tier matrix with Elastic before you design access controls, because feature placement changes between releases.

How much staff time does each platform need to operate?

Both platforms need people for capacity planning, upgrades, backup and restore testing, retention tuning and on-call response, and the work scales with volume and the number of tenants. Elasticsearch clusters need dedicated node roles, a highly available cluster needs at least three master-eligible nodes, and shard sizing and lifecycle tiers need ongoing attention. Loki reduces index work but adds object storage operations, compactor management and a choice of deployment mode, and its simple scalable mode is being removed in Loki 4.0. Ask for a written runbook list and an estimate of monthly operating hours that covers each role, rather than relying on a single headcount figure.

Can our own team migrate from Elasticsearch to Loki?

A team with Linux, object storage and Kubernetes or VM operations experience can run a pilot, but a production migration usually involves more than swapping the store. You must rework ingestion so that Alloy, Fluent Bit, Fluentd or OpenTelemetry sends logs with a stable label scheme, translate Kibana and Elasticsearch queries into LogQL, migrate alerts, and decide how historical data is handled, since Loki's retention is disabled by default. Elastic data does not map one-to-one onto Loki streams. Document which dashboards, detections and retention rules must be rebuilt, and run both platforms in parallel long enough to compare results.

Can Loki replace a SIEM for security log search?

Loki can store and search security logs with LogQL, which suits fast queries filtered by labels such as host, namespace or service. It does not provide the detection content, case management, correlation rules or threat intelligence integrations that a SIEM product typically bundles, and Loki has no built-in authentication layer, so you must place an authenticating reverse proxy in front of it. Full-text search across message bodies is slower than in an inverted index, and that matters for investigations that pivot on arbitrary strings. Confirm with your security team which detections, retention periods and audit requirements apply before you decide whether Loki covers the SIEM role or only part of it.

Does DeployOpen help with the Loki or Elasticsearch decision?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and it runs security testing and prepares evidence for compliance assessments. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from a written scope that covers your volumes, retention, identity integration, shipper inventory and migration requirements. Ask for a scope that separates the platform decision from the implementation work.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the choice between Loki and Elasticsearch is made against your environment rather than a generic benchmark. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not favor either platform. If your evidence points to Elasticsearch because you need full-text search across unstructured fields, or to Loki because your queries are mostly label-based and retention is long, the work follows that conclusion.

Before any build, the most useful step is a written test of your own workload. Ask for a sizing review that records daily ingest volume, the label set you expect to keep, the fields your analysts search by free text, the retention rules you must meet, and whether you need the Elastic Basic tier features or paid security features such as field-level security. For Loki, confirm the deployment mode you need (the docs list monolithic, simple scalable and microservices) and note that simple scalable mode is being removed in Loki 4.0. For Elasticsearch, confirm the node roles and at least three master-eligible nodes for a highly available cluster. Also confirm which Elastic license tier, Elastic License 2.0 or AGPLv3, your legal team accepts. These checks should be in the written scope before anyone is asked for a quote.

Where your organization needs security testing or compliance readiness, DeployOpen can run those as separate, scoped work, such as testing the log pipeline's authentication and tenant isolation or preparing the evidence a compliance assessment will request. DeployOpen prepares systems, controls and evidence, but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. DeployOpen is also not an official partner or reseller of Grafana Labs or Elastic. Ask any provider, including DeployOpen, to put the deliverables, the exit or migration path between the two stores, and the ongoing support model in writing so the switching cost is visible before you commit.

Loki vs Elasticsearch