Loki vs ELK vs OpenSearch: how to choose a production logging stack

Modern systems produce enormous log volumes - containers, sidecars, Lambdas, gateways. The wrong logging stack quietly drains money, hides real incidents, and turns every P1 into grep roulette. This is a practical, production-focused comparison of Loki, ELK, and OpenSearch across cost, scaling, query patterns, cloud alignment, and operational overhead.

1. The three stacks in one sentence each

• Loki - log aggregation that indexes only labels and stores log bodies cheaply in object storage. Best for Kubernetes + Prometheus/Grafana shops; very cost-efficient. (Loki system architecture)
• ELK (Elasticsearch + Logstash + Kibana + Beats) - the classic full-text log analytics stack; powerful search and dashboards, but heavy and expensive to run at scale. (elastic.co)
• OpenSearch (+ OpenSearch Dashboards) - community fork of Elasticsearch 7.10, still Lucene-based, similar architecture, with open-source licensing and strong AWS alignment.

If you remember nothing else: Loki = cheap and Kubernetes-native; ELK = rich search but heavy; OpenSearch = an open ELK engine, AWS-friendly.

2. Architectures at a glance

2.1 Loki: labels, chunks, and object storage

Loki is designed to be Prometheus for logs: it treats logs like time series.

• Only labels (metadata) are indexed (e.g., namespace, pod, app, env).
• Log lines are stored in compressed chunks in object storage (S3, GCS, etc.).
• Query flow:
  1. Find streams by label filters in the index.
  2. Pull relevant chunks from object storage.
  3. Scan/filter log text on the fly using LogQL. (Grafana Labs: architecture)

Implication: storage is cheap (object storage) and scales horizontally, but bad label design destroys performance - high-cardinality labels are the main failure mode.

2.2 ELK: full-text search engine for logs

ELK wraps logs around Elasticsearch, a Lucene-based search/analytics engine. Typical components:

• Beats/Filebeat/FluentBit - ship logs.
• Logstash - parse, enrich, transform.
• Elasticsearch - store logs as documents, index fields and content.
• Kibana - dashboards, queries, alerting.

Every log line is a document with indexed fields. ELK is strong for free-text search ("find this stack trace anywhere across 7 days"), aggregations, visualizations, and SIEM/observability add-ons. The flip side: index storage is expensive, and cluster tuning (shards, replicas, ILM policies, hot/warm tiers) is non-trivial.

2.3 OpenSearch: the open, AWS-friendly Elasticsearch fork

OpenSearch is the community fork of Elasticsearch/Kibana from before the license change. It keeps the same mental model: a cluster of nodes, indexes, shards, Lucene.

• Open-source (Apache 2.0), backed heavily by AWS.
• Similar features: full-text search, aggregations, dashboards, alerting, observability plugins.
• Often used via Amazon OpenSearch Service for managed clusters.

If you know Elasticsearch, you're 80-90% of the way to understanding OpenSearch.

3. Loki vs ELK vs OpenSearch - comparison table

Dimension	Loki	ELK (Elastic Stack)	OpenSearch
Indexing model	Labels only	Full-text + structured fields	Full-text + structured fields
Storage backend	Object storage (chunks)	Local/remote disk for indices	Local/remote disk for indices
Primary strength	Cost, k8s-native, Prometheus synergy	Deep analytics, mature ecosystem	Open-source ELK-style engine, AWS ecosystem
Search style	Label-first, then scan logs	Arbitrary full-text + aggregations	Same as ELK (Lucene-based search)
Best for	Cloud-native metrics+logs correlation	Security/SIEM, complex investigations	Cloud (esp. AWS) log/search with open licensing
Operational overhead	Low - medium (label design is key)	Medium - high (shards, ILM, JVM tuning)	Medium - high (similar to ELK)
Cost at scale	Usually lowest	Usually highest	Between ELK & Loki; depends on infra

If you're all-in on Kubernetes + Prometheus, starting with ELK is usually overkill and a future cost bomb. If you're doing compliance/SIEM-style investigations, Loki alone is usually not enough.

4. Example architectures & configs

4.1 Loki + Promtail + Grafana (Kubernetes)

Flow: Pods → stdout → Promtail DaemonSet → Loki → Grafana dashboards.

Minimal promtail snippet for Kubernetes logs:

server:
  http_listen_port: 9080
  grpc_listen_port: 0

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    pipeline_stages:
      - docker: {}
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace

Here you're explicitly controlling labels - this is your performance and cost control panel.

4.2 ELK: Filebeat + Logstash + Elasticsearch + Kibana

Flow: Apps / servers → Filebeat → Logstash → Elasticsearch → Kibana.

Minimal filebeat snippet for log shipping:

filebeat.inputs:
  - type: log
    paths:
      - /var/log/*.log
    fields:
      env: prod
      app: payments

output.logstash:
  hosts: ["logstash:5044"]

In Logstash, you parse and enrich:

input {
  beats {
    port => 5044
  }
}

filter {
  json {
    source => "message"
    skip_on_invalid_json => true
  }
  mutate {
    add_field => { "app_env" => "%{[fields][env]}" }
  }
}

output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "logs-%{+YYYY.MM.dd}"
  }
}

All parsed fields become indexed for fast queries.

4.3 OpenSearch: FluentBit + OpenSearch Dashboards

Swap Elasticsearch/Kibana for OpenSearch/OpenSearch Dashboards; the ingestion stack stays similar. Example Fluent Bit → OpenSearch:

[OUTPUT]
    Name            opensearch
    Match           *
    Host            opensearch-cluster
    Port            9200
    Index           logs-${TAG}
    Suppress_Type_Name On
    HTTP_User       fluent_user
    HTTP_Passwd     ${FLUENT_PASSWORD}

Same pattern: each log is a JSON document in an index.

5. How to choose for production

5.1 Choose Loki if...

• You are heavily Kubernetes + Prometheus/Grafana already.
• Your main workflows are "show me logs for this pod/service around this alert" and "correlate this metric spike with logs."
• You care about cost and S3-based retention.
• You can enforce sane label hygiene (no user_id, request_id as labels). (Grafana Labs: labels)

You accept that ad-hoc text search across 30 days of logs won't be as fast as ELK, and some complex investigations are more manual.

5.2 Choose ELK if...

• You need strong security / compliance / SIEM capabilities on top of logs.
• Your teams already have Elasticsearch skills and operational muscle.
• You require deep aggregations and dashboards over log fields, advanced search (regex, fuzzy, proximity), and ecosystem integrations (APM, SIEM).

You accept significant time on index lifecycle policies, shard sizing, and JVM tuning, and that at scale you must implement hot/warm/cold storage to control storage bills.

5.3 Choose OpenSearch if...

• You want ELK-style capabilities but prefer fully open-source licensing, or are invested in AWS and want Amazon OpenSearch Service.
• You don't need every closed-source Elastic-only feature but want full-text search, aggregations, dashboards, alerting, and observability plugins.

You accept that the ecosystem and docs are slightly less polished than Elastic's, and you carry roughly the same operational complexity as ELK.

6. Hybrid & migration patterns

Many organizations end up with hybrid architectures rather than choosing one stack forever. Common patterns:

1. Loki for fresh operational logs + OpenSearch for compliance audit logs. Loki: 7-14 days, cheap, used by SREs. OpenSearch: 90-365 days, a limited subset of logs (auth, payments, PII-sensitive).
2. Start with Loki, later mirror critical streams into ELK/OpenSearch. Use Promtail/FluentBit to dual-ship only key log streams. Most traffic stays in Loki; only high-value logs hit the expensive search engine.
3. Migration from ELK → OpenSearch. For cost/licensing reasons, retain the ingestion pipeline and swap the backend cluster.

Centralizing absolutely everything into ELK forever is how you end up explaining a six-figure log bill to finance.

7. Best practices & common pitfalls

7.1 Loki

• Design labels explicitly - only stable, low-cardinality labels: namespace, app, cluster, env. Treat labels as dimensions, not "whatever metadata we have."
• Use logs + metrics together - drive Loki queries from Prometheus alerts.
• Use object lifecycle policies on S3/GCS - archive to Glacier / Coldline after X days if you rarely query old logs.

Pitfalls: putting request_id, user_id, or headers as labels causes a cardinality explosion and cluster meltdown; treating Loki as "Elasticsearch but cheaper" and expecting identical search ergonomics.

7.2 ELK / OpenSearch

• Index lifecycle management (ILM) from day one - hot (SSD, frequent queries) → warm (slower, cheaper) → cold/frozen.
• Template your index mappings - don't let everything be text+keyword by default; narrow mappings where possible.
• Limit high-cardinality fields - don't index giant random strings like raw stack traces or correlation IDs if you don't need to search by them.
• Apply sampling or log-level policies - you rarely need all debug logs from every sidecar in prod.

Pitfalls: "just ship all logs, we'll clean it up later" (you won't, and the cluster suffers); one giant index for everything instead of per-app / per-namespace patterns; no alerting on cluster health (heap, disk watermark, queue sizes).

8. Quick decision checklist

1. Primary platform? Mostly Kubernetes + Prometheus → start with Loki. Mixed legacy VMs, appliances, Windows → ELK or OpenSearch.
2. Main usage pattern? "Show me logs for this service around 10:32 UTC" → Loki wins. "Search for this error text across the fleet over 30 days" → ELK/OpenSearch wins.
3. Budget & team capacity? Small SRE team, cost pressure → Loki or managed OpenSearch. Larger team, observability-platform ambitions → ELK or OpenSearch.
4. Regulatory/compliance requirements? Long retention, forensic investigations → ELK/OpenSearch for the retained subset.

If you're still torn: use Loki as your default logging plane, and send only high-value security/transaction logs to ELK/OpenSearch. That's the sane middle ground.

9. Conclusion & takeaways

• Loki is the go-to for cheap, scalable, Kubernetes-centric logging tightly integrated with Prometheus and Grafana.
• ELK remains the powerhouse for rich log analytics and SIEM, but you pay in money and operational complexity.
• OpenSearch gives ELK-style capabilities with open licensing and strong AWS integration.

In practice, the best setups are intentional hybrids, not tool monocultures. Treat logs as a product: define consumers, retention, and query patterns before choosing the engine.