Loki vs Elasticsearch

Grafana Loki vs Elasticsearch for Kubernetes log aggregation: label-based cheap storage vs full-text indexed search power.

observabilityloggingkuberneteslokielasticsearch

Back to Toolkit

Feature Matrix	Grafana Loki Log aggregation system that indexes only labels — cheap, K8s-native, and Grafana-integrated.	Elasticsearch Full-text search and analytics engine with powerful querying, aggregations, and Kibana dashboards.
Indexing Model Loki's label-only indexing is what makes it cheap. Elasticsearch indexes everything, enabling powerful search.	Labels only (no full-text index of log content)	Full-text inverted index on all log fields
Storage Cost At scale, Loki can be 10x cheaper than Elasticsearch for the same log volume.	Low — compressed chunks in object storage (S3/GCS)	High — indexed data requires 3–5x the raw log size on disk
Query Language LogQL is simpler for K8s log queries. Elasticsearch's DSL is more powerful for analytics.	LogQL (label filtering + regex + metric queries)	Kibana Query Language (KQL) + Elasticsearch DSL
Full-Text Search If you need to search arbitrary log content across millions of lines, Elasticsearch is faster.	Regex-based (slow on large volumes without good labels)	Native full-text search (fast, ranked results)
Kubernetes Integration Loki + Promtail is the canonical K8s logging stack — designed for label-based pod log collection.	Native (Promtail, Grafana Agent, Alloy collectors)	Requires Filebeat or Fluentd/Fluentbit with Elasticsearch output
Operational Complexity Elasticsearch requires significant ongoing ops: shard rebalancing, heap tuning, index lifecycle policies.	Low-Medium (Loki in microservices mode or simple mode)	High (Elasticsearch cluster tuning, shard management, JVM tuning)
Alerting Loki's alerting integrates natively with the Grafana/Prometheus stack.	Native ruler component sends alerts directly to Alertmanager; also via Grafana alerting	Via Elasticsearch Watcher or Kibana Alerts
Retention & ILM Elasticsearch's ILM is more sophisticated. Loki relies on object storage TTLs.	S3 lifecycle policies or Loki retention config	Index Lifecycle Management (ILM) with rollover, warm/cold/delete phases
Structured Log Analytics For business intelligence or compliance reporting on log data, Elasticsearch is the right choice.	Limited — works best with line-filter + label queries	Excellent — aggregations, cardinality, percentiles, histograms

Overview

Loki and Elasticsearch answer different questions. Loki asks: what logs does this pod/namespace/label-set have, right now? It indexes only labels (pod name, namespace, container) and stores raw log lines compressed in object storage — making it dramatically cheaper than Elasticsearch at scale. Elasticsearch asks: across all my logs, show me every line containing 'OOMKilled' in the last hour, ranked by relevance. Its full-text inverted index enables queries Loki can't efficiently answer. The right choice depends on whether you're doing Kubernetes operations or log analytics.

Where Loki Wins

Loki is the right choice for Kubernetes log aggregation when your primary use case is operational: reading logs for a specific pod, filtering by namespace, or detecting patterns in a known service. Storage costs are typically 80–90% lower than Elasticsearch for the same retention period because Loki compresses and ships chunks directly to S3 without indexing content. The PLG stack (Promtail + Loki + Grafana) integrates naturally with your existing Prometheus/Grafana dashboards. For most platform teams, Loki covers 90% of log query needs at a fraction of the cost.

Where Elasticsearch Wins

Elasticsearch wins when you need to search arbitrary content across large log volumes, run structured analytics on log data, or build compliance reporting. Its full-text index answers queries like 'show all requests where response_time > 2s AND user_id = X' without scanning every log line. Kibana's Discover, Lens, and Canvas tools are significantly more powerful than Grafana's Explore for business-intelligence use cases. If your security team needs log correlation, your compliance team needs audit reports, or your application team runs complex analytics, Elasticsearch earns its operational cost.

Migration & Switching Cost

Migrating from Elasticsearch to Loki requires replacing your log shippers (Filebeat → Promtail/Alloy), re-training your team on LogQL (simpler than KQL but different), and accepting that some complex queries you run today may be slower or impossible in Loki. Going the other direction — Loki to Elasticsearch — requires provisioning an Elasticsearch cluster (significant ops work), installing and configuring Filebeat, and replacing LogQL queries with KQL. Budget 1–2 weeks for a production migration in either direction. The LogQL learning curve deserves particular attention: engineers accustomed to Elasticsearch's query DSL need time to adjust to LogQL's label-filter syntax, and Grafana Explore's interface differs significantly enough from Kibana Discover that expect a productivity dip for the first few weeks.

Final Verdict

For Kubernetes log aggregation, start with Loki. It's cheaper, simpler to operate, and integrates naturally with the Grafana stack your monitoring team already uses. Add Elasticsearch only when you need full-text search across arbitrary log fields, complex analytics, or compliance reporting that Loki's label-based model can't efficiently serve.

Monitoring Strategy: Prometheus vs Datadog

A practitioner's guide to choosing between open-source and SaaS observability — covering metrics, logs, and traces.

Read the Blog Post

Loki vs Elasticsearch: how to choose

Loki and Elasticsearch take opposite positions on the same question: how much of a log should you index? Elasticsearch indexes the content, so any field is queryable and aggregations are fast. Loki indexes only labels and stores the log body compressed, so queries filter by label and then scan.

That decision drives everything downstream — cost, query shape and operational burden. Loki is dramatically cheaper to store and simpler to run, because there is far less index to build, hold and shard. Its constraint is that a query which cannot be narrowed by labels becomes a scan, and a scan over a wide time range is slow.

Elasticsearch costs more in storage and in operational attention, and pays it back in query power. Full-text search across arbitrary fields, aggregations, and analytics over log content are things Loki is not built to do well.

Label cardinality is the thing that will hurt you

Loki's efficiency depends entirely on keeping label cardinality low. Labels should describe the stream — namespace, app, container, level — and never the request. Putting a user ID, request ID, trace ID or pod IP in a label creates a separate stream per value, and the index Loki was designed to avoid building reappears in the worst possible shape.

This is the single most common way a Loki deployment goes wrong, and it degrades gradually rather than failing outright: ingestion slows, queries get expensive, and memory grows until someone investigates. Decide the label schema before you onboard services, and treat adding a label as a change requiring review.

Decision matrix: which one fits your situation

Your situation	Use	Why
Kubernetes logs, already running Grafana	Loki	Same query ergonomics and datasource as your metrics; cheap object storage retention.
Full-text search across log content	Elasticsearch	Loki cannot do this well by design — it does not index the body.
Analytics and aggregations over log fields	Elasticsearch	Aggregations are what the inverted index is for.
Storage cost is the binding constraint	Loki	Object storage plus a small index is far cheaper than a full content index.
Security analytics, SIEM-style correlation	Elasticsearch	Correlation across arbitrary fields is the core requirement, and Loki is the wrong shape.
Small team, no search specialist	Loki	Far less to tune. Elasticsearch cluster management is a real skill set.

Frequently asked questions

Is Loki really cheaper?

Substantially, for the usual Kubernetes case, and for a structural reason rather than a pricing one: you are storing compressed logs in object storage with a small index instead of a full content index on fast disks. The saving evaporates if you misuse labels — high cardinality recreates the index cost you were avoiding, plus memory pressure.

Can I run both?

Yes, and it is a reasonable split: Loki for the high-volume application logs where you almost always know the service and time range, Elasticsearch for the subset needing full-text search or long-term analytics — audit and security logs, typically. The cost is two pipelines and two mental models, so route deliberately rather than duplicating everything into both.

How does LogQL compare to Elasticsearch queries?

LogQL will feel immediately familiar if you know PromQL: select streams by label, then filter and optionally aggregate. It is well suited to "show me errors from this service in this window". It is not a search language — if your question begins with an unknown service and a string to find everywhere, Elasticsearch is the right tool.

What about OpenSearch?

OpenSearch is the fork of Elasticsearch that AWS created after the 2021 licence change; since September 2024 it has been governed by the Linux Foundation's OpenSearch Software Foundation rather than by AWS alone. For log use cases it is broadly comparable. Everything above about indexing trade-offs applies equally. Choose between them on licensing, managed-service availability and ecosystem preference rather than on log-handling capability.