The ELK Stack in 2026: Still Worth the Memory Bill?

Short answer: ELK is still the best full-text search engine you can point at logs, and it is still the most expensive way to store them. Whether ELK stack log management makes sense for you in 2026 comes down to one question — do you actually search your logs, or do you filter them?

Most teams filter. They query by service name, status code, trace ID, time range. Structured field lookups, over and over. For that workload, Elasticsearch is a Ferrari doing grocery runs, and the fuel bill is denominated in RAM.

But some teams genuinely search. Free-text over unstructured payloads, fuzzy matching, “find every log line mentioning this customer’s email across nine services.” For them, nothing else really competes, and the memory bill is the cost of doing business.

Let me lay out where each side of that line falls, because I have run ELK clusters through enough 3am shard-rebalancing incidents to have earned an opinion.

What ELK still does better than anything

Elasticsearch builds an inverted index over your log text. Every token, findable in milliseconds, across terabytes. Aggregations on top of that. Kibana remains a genuinely good exploration UI — after fifteen years of iteration, it should be.

If your incident workflow involves grepping for a stack trace fragment you half-remember, or your support team searches logs by customer-visible strings, ELK earns its keep. Loki will make you wait while it brute-forces chunks. ClickHouse will make you write a LIKE query and think about which columns you materialized. Elasticsearch just answers.

The ecosystem maturity matters too. Beats, Logstash, Elastic Agent, ingest pipelines, a decade of Stack Overflow answers, and official docs at elastic.co that cover nearly every failure mode. When something breaks, someone has broken it before you.

What it costs you

Here is where I stop being polite.

JVM heap. Elasticsearch wants heap, and the long-standing guidance caps it around 30–32GB per node to keep compressed object pointers. Below that ceiling, you are perpetually rationing: field data, query caches, indexing buffers, aggregation memory. An ELK cluster that “needs more capacity” almost always means “needs more RAM,” and RAM is the expensive dimension in every cloud.

Shard management. Shards are the unit of everything in Elasticsearch — distribution, recovery, heap overhead. Too many small shards and your master node drowns in cluster state. Too few large ones and recovery after a node loss takes hours. The commonly cited sweet spot is tens of GB per shard, and hitting it requires index lifecycle policies, rollover configuration, and periodic hand-holding. This is a part-time job. I have watched it become a full-time one.

Upgrades. Major version upgrades in the Elastic world are events. You read breaking-changes docs, you test reindexing paths, you schedule a window. Compare with Loki, where an upgrade is mostly a container tag bump, and the difference in operational posture is stark.

Storage amplification. An inverted index over every field is not free. Depending on mappings, logs in Elasticsearch commonly occupy as much as or more disk than the raw input. Columnar stores routinely compress the same data 10x or better, because log data is repetitive and columnar compression feasts on repetition.

The index-light alternatives

Two architectures ate into ELK’s territory over the last five years, from opposite directions.

Loki indexes almost nothing — just labels like {app="checkout", env="prod"}. Everything else is compressed chunks in object storage, scanned at query time. Cheap to run, cheap to store, brilliant for “show me this pod’s logs from 2pm.” Painful the moment you need a needle-in-haystack search across a month of data, because there is no index to help you. Grafana’s docs at grafana.com are upfront about this trade.

ClickHouse-based systems take the middle path: columnar storage with sparse primary indexes, ordered by whatever you query most (usually time plus a service or session key). Field-filter queries are fast because they skip data at the block level; compression is excellent; full-text search is possible but not the native strength. A growing number of observability products — including session replay and logging tools like LogReplay — settled here precisely because log-shaped data compresses brutally well in columns. I wrote more about that trade-off in Elasticsearch for logs: powerful, hungry, and often overkill.

A rough qualitative comparison:

Who should still run ELK stack log management

Genuinely, some of you should. Pick ELK in 2026 if:

• Search is the product requirement. Compliance teams doing free-text discovery, security teams hunting across unstructured payloads, support engineers searching by arbitrary strings. If “grep everything, fast” is the job, buy the tool built for it.
• You already have the expertise. A team that has run Elasticsearch for years, knows its shard math, and has ILM policies that work — that team’s marginal cost of continuing is low. Migrations have costs too, and “we might save on RAM” is a weak reason to spend two quarters replatforming.
• You need the aggregation depth. Kibana’s ad-hoc aggregations over high-cardinality fields still outclass most alternatives for exploratory analysis.

And you are probably buying a boat — an expensive hobby disguised as infrastructure — if:

• Your team is under ten engineers and nobody wants to own the cluster.
• Your queries are 95% “filter by service, status, and time.” You are paying inverted-index prices for columnar-query needs.
• You chose ELK because a tutorial in 2019 said to. That was a different decade. The tutorial author is not on your on-call rotation.

My actual recommendation

If you are starting fresh at small scale: do not start with ELK. Start with structured logging into something index-light or columnar, and add real search only when a concrete workflow demands it. You can always graduate to Elasticsearch later; the reverse migration — off a cluster your dashboards and alerts have grown into — is the one that hurts.

If you are already on ELK and it works: keep it, but be honest in the annual review. Add up the node RAM, the storage, and the fraction of an engineer who tends it. If that number makes you wince and your query log shows mostly field filters, the exit is easier than it looks.

The ELK stack in 2026 is not obsolete. It is specialized. It spent a decade being the default, and defaults accumulate users who never needed them. The memory bill is worth paying when you use what the memory buys. Most teams, checking their own query patterns honestly, will find they do not.