Open Source Observability

Chapter 5. Optimizing Storage and Query for Performance

With a disaggregated observability stack, users can decide what storage solution works best for their telemetry and use cases. Traditionally, there have been many different types of storage systems, optimized for each pillar of observability. For example:

Metrics

Prometheus, Timescale, InfluxDB, and other time series databases or key-value stores

Logs

Grafana Loki, plus Elasticsearch, OpenSearch, and other search engines

Traces

Grafana Tempo, Jaeger, Hypertrace, and other column stores

More recently, real-time analytical databases like Apache Pinot and ClickHouse have been increasingly used for observability use cases because they can support more than one “pillar” in a common repository (i.e., the “Observability 1.5” mentioned in Chapter 3).

Let’s look at other ways to mix and match databases within a disaggregated stack. The Jaeger platform is truly versatile, with many different community-supported backend storage options, such as PostgreSQL, Cassandra, and ClickHouse (“Additional Storage Backends” 2025). Each of these storage options provides very different capabilities, including in their supported rates of ingestion, query performance, and query flexibility (Jegadish 2023).

However, users have also bypassed the Jaeger storage backend entirely, streaming telemetry from Jaeger agents directly into Apache Pinot for real-time analysis (StarTree 2024).

Let’s dig a little deeper into what makes for a good match for an observability ...