Loki versus Elasticsearch for logs

WHAT THIS TESTS Whether you understand that Loki and Elasticsearch sit at opposite ends of an indexing spectrum, and that the data model directly determines cost, query speed, and flexibility.

A GOOD ANSWER COVERS Loki indexes only a small set of metadata labels, such as app, namespace, and level, and stores the actual log lines as compressed chunks in object storage like S3. This makes ingestion and storage very cheap and keeps the index tiny. The cost is that searching log content requires first selecting a label stream, then brute-force scanning the matching chunks with a filter expression; broad queries without good label selectors are slow and read a lot of data. Elasticsearch builds inverted indexes over the full text of each log document, so arbitrary keyword and field queries across all logs are fast and flexible, and it supports rich aggregations. The price is high: indexing is CPU and memory intensive, the index itself is large and often exceeds raw data size, and storage and cluster costs are substantial. So Loki optimizes for cheap storage and label-scoped queries; Elasticsearch optimizes for fast, flexible full-text search at higher cost.

COMMON WRONG ANSWERS Claiming Loki is always cheaper with no downside, ignoring slow content scans. Saying Elasticsearch is strictly better, ignoring cost and operational weight. Thinking Loki full-text indexes everything like Elasticsearch.

LIKELY FOLLOW-UPS How does label cardinality hurt Loki? When would slow ad hoc search be unacceptable? How do retention and object storage change the cost picture?

ONE CONCRETE EXAMPLE For Kubernetes logs where teams mostly filter by namespace and pod and occasionally grep for an error string, Loki is far cheaper and adequate. For a security team running varied ad hoc full-text investigations across all logs with complex aggregations, Elasticsearch's inverted index makes those queries fast, justifying its higher cost.