Elastic, Loki and SigNoz – A Perf Benchmark of Open-Source Logging Platforms
Benchmarks are always &quot;It depends&quot;.<p>And what it depends on are your data volume, how you want to query, whether you value ingestion greater than query speed and timeliness and so forth.<p>Elastic sweet spot is that it indexes everything, and you can query fast as a result. But it does this at the cost of ingest as it&#x27;s doing the work to build indexes during ingestion and so ingest is more CPU intensive and can hit limits here. As a general purpose workhorse, Elastic shines.<p>Loki sweet spot is that it has very few indexes, so ingestion is cheap and extremely capable for huge data volumes. It does this at the cost of query performance over very large data sets - without indexes queries brute force via mapreduce, which means you really want to specify where to look (which log streams) and when to look (a time window) and in that it excels. For logs, Loki is heaven.<p>ClickHouse sweet spot is the indexes (columns) are very explicitly configured by engineers who know what the data looks like and how they want to query it. Now the ingest cost is balanced, and the query performance is great - but it did this at the cost of you knowing your data and how you&#x27;re going to query it most of the time - it&#x27;s not so good for esoteric questions that you&#x27;d never anticipated (though you can get very far through some of their column data types allowing you to be reasonably flexible on this). For BI data, ClickHouse is incredible.<p>They all have sweet spots, and a benchmark is not going to answer the real questions - what data volume do you have, what do you value (ingest and preserve everything vs fastest query speed for ad-hoc queries vs a balanced approach), do you know how you want to query the data, etc?<p>Other thoughts:<p>Loki has recently moved to TSDB for the backend storage, these benchmarks don&#x27;t go there.<p>Elastic can use less disk if you configure for synthetic source (<a href="https:&#x2F;&#x2F;github.com&#x2F;elastic&#x2F;elasticsearch&#x2F;issues&#x2F;86603">https:&#x2F;&#x2F;github.com&#x2F;elastic&#x2F;elasticsearch&#x2F;issues&#x2F;86603</a>) which discards the raw byte copy of the ingested data and only retains knowledge in the indexes, and uses the indexes to reconstruct the source should you request it. Enabling this is only supported by ES for metric type data (according to docs) but it is possible to enable it for other types of data.<p>Nothing to add about ClickHouse, I&#x27;ve used all three databases and worked against all three for huge volumes of data - if I want a more OLAP style querying than OLTP and I know my data then today ClickHouse absolutely shines here with the others playing catch up. Elastic and Loki shine far more for OLTP workloads, so it&#x27;s a trade-off again (though Elastic does a good job at doing pretty well for more OLAP cases than Loki does today due to it having column storage - and Loki wins on being able to ingest more cheaply - meaning being able to ingest more at the same or lower cost).<p>What you value and what you want to do is up to you.