ClickHouse source code is published under the Apache 2.0 License. Software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

logo_without_text.svg

Stay informed on feature releases, product roadmap, support, and cloud offerings!

Subscribe to our newsletter

icon-github.svg

icon-slack.svg

icon-telegram.svg

icon-twitter.svg

Join the ClickHouse conversation on

ClickHouse

ClickHouse Cloud

Download

PRODUCT

Documentation

Training

Support

Comparison

Use cases

RESOURCES

Blog

Our story

Careers

Contact us

News and events

COMPANY

Linux, macOS, FreeBSD

Frequently asked questions

How to engineer cost-efficient open source observability with ClickHouse (ClickStack) - 2026 technical playbook

* **The problem:** The traditional "three pillars" model of observability (logs, metrics, traces) is broken. Siloing data in specialized systems like Elasticsearch and Prometheus creates complexity, high costs, and slow analysis, making it impossible to debug modern "unknown-unknowns."  
* **The shift:** Observability in 2026 is a high-performance data analytics problem, not a data collection problem. The new standard is to unify all raw, granular telemetry into a single data store that allows for fast, exploratory queries to answer any question.  
* **The solution:** The database is the central component of your observability platform. A columnar analytical database like ClickHouse provides the necessary architecture. It is engineered to handle granular data at scale, using vectorized execution, data skipping, and parallel processing to deliver sub-second query performance and cost-efficiency.

As modern systems grow more complex, engineering teams face a paradox: observability costs skyrocket while critical answers remain elusive during outages. This challenge stems from architecture rather than data volume. In 2026, true observability represents a high-performance data analytics problem rather than a signal collection task.

This architectural challenge is particularly acute for teams building their own observability solutions or those hitting the performance and cost ceilings of managed SaaS platforms. While such platforms abstract away the underlying database, their architectural choices ultimately dictate the cost, query speed, and analytical depth available. For teams seeking to overcome these limitations, understanding the data layer is no longer optional \- it is the central challenge. This article explores why the "three pillars" model fails, the specific architectural limitations of legacy tools, and why your database choice dictates the success of your entire platform.


Summary

## Why is the traditional "three pillars" model broken?

The "three pillars of observability" framework emerged to address the complexity of distributed systems. However, this led to a fractured ecosystem of specialized tools, each optimizing for a single data type: Prometheus for metrics, the ELK stack for logs, and Jaeger for traces. While this "best-of-breed" approach seemed cost-effective initially, it created a deep architectural flaw: data silos. This model became a primary source of friction, trapping engineers between three difficult choices: a piecemeal and complex open-source stack, an expensive proprietary SaaS platform, or a resource-intensive DIY effort.

### The user pain: disjointed analysis and runaway costs

The fundamental flaw of the three-pillars model is that it forces users to correlate data manually. During an incident, this fragmentation necessitates a slow workflow. An engineer receives an alert in Grafana, pivots to Kibana to hunt for related logs, then jumps to Jaeger to find a connecting trace. Each pivot is a context switch across different UIs and query languages, increasing Mean Time to Resolution (MTTR).

Modern tools attempt to mask this with UI-level linking, but this is a superficial fix. Because the data lives in separate databases, you cannot perform deep analytical queries across signals. You cannot write one query to join metric spikes with log attributes and trace durations. This rigidity prevents the investigation of complex "unknown-unknowns" that define modern outages. Furthermore, the architecture is inefficient. Essential context like a `trace_id` or `customer_id` duplicates across all three data stores, inflating storage costs. Beyond storage, scaling, securing, and maintaining multiple distinct, stateful systems imposes a significant operational tax.

While a unified model makes sense for most systems, a best-of-breed approach can be justified in hyperscale environments where a single dominant signal produces multiple gigabytes per second. In these cases, it can be financially rational to optimize specifically for that signal. For the vast majority of workloads, however, a unified model delivers better efficiency, simplicity, and analytical leverage.

### The architectural mismatch: why legacy databases fail

The symptoms of a struggling observability platform include slow queries, forced data sampling, and ingestion lag. These issues result from architectural mismatches. The data engines powering most traditional observability tools (time-series databases and search indexes) were designed for specific, narrower use cases and are structurally unsuited for the high-dimensionality and analytical demands of modern systems.

**Table 1: Database architectures compared**

| Database type | High-cardinality handling | Analytical query performance | Operational complexity at scale | Insert performance |
| :---- | :---- | :---- | :---- | :---- |
| **Log search engine** (e.g., Elasticsearch) | **Poor**. Aggregations on high-cardinality fields create heavy memory pressure. While scalable for search, deep analytics at high cardinality hit JVM heap limits. | **Poor**. Optimized for text search ("needle-in-a-haystack"), not for fast, complex aggregations. | **High**. Requires managing heavy indices and shard rebalancing as data volume grows. | **Low**. Inverted indices produce significant write amplification and require ingest time string tokenization and processing. |
| **Time-series database** (e.g., Prometheus) | **Poor**. Granular labels cause a "combinatorial explosion," leading to system instability and memory exhaustion. | **Poor**. Efficient for pre-defined numerical metrics but struggles with ad-hoc analysis on raw event data. | **Moderate**. Forces teams to drop valuable context (labels) to maintain stability. | **Moderate**. Fast write performance is possible provided cardinality isn't high. |
| **Columnar analytical database** (e.g., ClickHouse) | **Excellent.** Designed to treat high-cardinality data as a simple feature, storing it efficiently without performance degradation. | **Excellent.** Engineered for sub-second aggregations and deep analysis on raw, unsampled data at petabyte scale. | **Moderate**. Requires expertise in distributed database tuning and schema design. | **High**. Inserting requires data to be sorted at insert time and compressed. This can be done efficiently delivering GB/s insert rates on moderate hardware. |

#### The time-series database trap: cracking under granularity

Time-series databases like Prometheus are architecturally mismatched for modern observability due to the "cardinality" challenge. Their data model creates a unique time series for every distinct combination of a metric name and its key-value labels. In high-cardinality scenarios, such as tracking metrics per container in large Kubernetes clusters or tracking individual user sessions, a single metric can expand into millions of time series. This creates massive memory pressure and requires careful label management to prevent system instability.

While highly performant for fetching pre-defined metrics for a single time series, this model fails when performing the exploratory aggregations across many series required for debugging. This forces teams into a trade-off: to prevent system collapse, they must drop the labels that provide context. By removing identifiers like `user_id` or `trace_id`, you sacrifice the ability to perform deep, ad-hoc analysis.

While processing at insert time is typically minimal, allowing fast ingestion rates, high cardinality severely degrades insert performance \- each new label set creates a new in-memory time series, index entries, and WAL writes, driving up memory usage and write amplification. As series churn grows, ingestion slows, WAL and head block size balloon, and the system becomes increasingly unstable even before queries run.

#### The log search engine gap: built for search, not analytics

Log management platforms like Elasticsearch are masters of full-text search, built around an inverted index that excels at finding specific text strings. However, this architecture creates an analytics gap when tasked with the complex aggregations essential for modern observability. Queries like `GROUP BY` or `COUNT DISTINCT` force these search engines to rely on secondary structures called "doc values."

This creates a performance ceiling. While Elasticsearch can perform aggregations, it is constrained by JVM memory management and the computational overhead of maintaining inverted indexes for analytical workloads. Using a log search engine for deep analytics is an architectural compromise that becomes inefficient as data volumes grow. Companies like Didi migrated their logging platforms from Elasticsearch to ClickHouse to overcome these specific scaling and cost limitations.

Additionally, search engines like Elasticsearch struggle with insert performance because every document must be tokenized, analyzed, and written into multiple inverted index structures, requiring expensive string processing, sorting, and index maintenance that amplifies write cost as data volume and field cardinality grow. This requires users to scale their compute horizontally in order to handle even moderate insert workloads.

## What is the new standard for observability?

The new standard redefines observability as the ability to explore "unknown unknowns." This is essential for debugging "unknown unknowns": emergent and unpredictable failure modes you didn't anticipate and thus couldn't pre-emptively monitor. It moves beyond the siloed "three pillars" model by unifying metrics, logs, and traces into a single, high-performance data store. This approach ingests raw, high-fidelity event data, treating observability as a data analytics problem rather than a storage challenge.

Implementing this standard requires three components: standardized collection (e.g., OpenTelemetry), high-performance storage (e.g., ClickHouse), and visualization (e.g., Grafana, HyperDX). Open-source stacks demonstrate this unified approach in practice. By consolidating all telemetry into a single unified data store, teams can correlate signals without complex joins or context switching.

### From monitoring "knowns" to exploring "unknowns"

The shift from monitoring to observability redefines the questions we can ask. Monitoring focuses on "known unknowns" and uses dashboards to track pre-defined metrics like CPU utilization or error rates. These are vital for tracking expected behavior.

Observability, conversely, is the ability to ask novel, exploratory questions of your system's telemetry. It is the difference between asking "What is our average error rate?" and "For users on the new mobile client in Germany who experienced latency over 500ms, which feature flag was enabled?"

### Why granular data is non-negotiable

When debugging a production incident, you need to answer questions like "Which specific users experienced errors?" But if you've aggregated away `user_id` to save costs, that question becomes impossible to answer. Aggregated data reveals symptoms (the *what*), but answering the *who*, *where*, and *why* requires raw identifiers. Dropping these fields to manage costs leaves you with alerts but no path to a solution.

This context is found in high-cardinality data: attributes with a vast number of unique values like `request_id` or `commit_sha`. This is why granular data is non-negotiable and retaining 100% of your unsampled data is necessary to diagnose the cause rather than just the symptom.

**Table 2: Traditional vs. unified observability models**

| Aspect | Traditional siloed model ("three pillars") | Modern unified analytics model |
| :---- | :---- | :---- |
| **Core concept** | Data collection into separate, specialized systems (logs, metrics, traces). | Unifying all telemetry into a single, high-performance analytics engine. |
| **Data** | Aggregated, sampled, or low-cardinality data to manage cost and performance. | Raw, unsampled, granular event data is retained for full context. |
| **Primary goal** | Monitoring "known-unknowns" with pre-defined dashboards. | Exploring "unknown-unknowns" with ad-hoc, exploratory queries. |
| **User workflow** | Manual correlation across multiple UIs. | Single-platform querying using SQL. |
| **Cost & complexity** | High TCO from data duplication across systems and operational overhead of multiple platforms. | Lower TCO from unified infrastructure and efficient compression, though requires database expertise. |

## How does ClickHouse deliver on the new standard?

Delivering on this new standard imposes clear technical requirements on the underlying data store \- real-time queries on raw data, support for high insertion rates, unlimited cardinality, and cost-efficient storage. The choice of database, therefore, becomes a critical architectural decision. The engine dictates whether you can actually deliver on the new standard or merely approximate it.

This requires a columnar database architecture. Unlike row-based systems that store all data for an event together, columnar databases group values by column: all timestamps together, all service names together. This structure, combined with vectorized query execution, yields significant advantages. First, it facilitates highly efficient compression because columns contain uniform data types. Second, analytical queries that only need a few columns (e.g., `service_name`, `status_code`) scan only relevant data, reducing I/O.

### Real-time performance: sub-second queries on raw data

During an outage, slow queries impede resolution. ClickHouse delivers sub-second query performance across petabytes of data. The key is the vectorized query engine, which operates on batches of column values rather than rows. This leverages SIMD (Single Instruction, Multiple Data) CPU instructions, which process multiple data points in parallel. This transforms debugging from a process measured in minutes to one measured in milliseconds, enabling interactive exploration.

### Insertion rates: support for high throughput

Observability systems must sustain extremely high insert rates because machine generated telemetry such as logs, traces, and events can produce massive, continuous throughput. Handling this efficiently requires a clear separation between read and write paths, but more importantly a write path that minimizes compute overhead. ClickHouse is designed for this model: writes are append oriented, data is only sorted into blocks by the ordering key at insert time, avoiding expensive per row processing. Skip indices are cheap to generate and evaluated at query time rather than insert time, which enables ClickHouse to ingest data at gigabytes per second on moderate hardware without excessive CPU consumption.

### Unlimited cardinality: from limitation to capability

In traditional systems, fields like `trace_id` are treated as liabilities. ClickHouse changes this dynamic. Adding a field with a billion unique values is a standard operation; it is simply another compressed file on disk. This layout avoids bloating a central index.

ClickHouse uses a sparse primary index that holds "checkpoints" for blocks of data rather than mapping every row. This allows the system to quickly skip large, irrelevant blocks of data. For fast point lookups on specific identifiers, ClickHouse utilizes Bloom filters to avoid full column scans. Consequently, dimensions once dropped for performance reasons are now available for any query. Shopee demonstrated this capability by searching specific trace IDs in a dataset of [over 30 billion rows](https://clickhouse.com/blog/seeing-the-big-picture-shopees-journey-to-distributed-tracing-with-clickhouse) in seconds.

### High cost-efficiency: store 100% of your data

ClickHouse's columnar architecture applies type-specific codecs to achieve compression ratios averaging [15-20x depending on data characteristics](https://clickhouse.com/resources/engineering/database-compression). This efficiency is enhanced by native support for tiered storage, allowing older data to move seamlessly to lower-cost object storage like S3 while remaining queryable. This decoupling of storage and compute allows teams to retain data for compliance and historical analysis at a fraction of the cost of index-heavy systems at scale.

## Considerations: Trade-offs and Migration

While a unified observability platform is the ideal end-state, migration does not require an all-or-nothing approach. Many teams find success by adopting ClickHouse in a "best-of-breed" capacity first \- for example, replacing an expensive logging solution like Elasticsearch while keeping their existing metrics and tracing pipelines. This phased approach allows teams to realize immediate cost and performance benefits for their most painful data silo before unifying other signals over time.

While ClickHouse offers superior analytics capabilities, it is not a drop-in replacement for every use case without consideration.

* **Migration Path:** Moving from ELK or Prometheus involves changing the storage backend. Teams typically migrate incrementally: first routing new trace data to ClickHouse via OpenTelemetry collectors while maintaining existing Jaeger/Tempo, then migrating logs and metrics after validating query patterns that meet SLA requirements \- often over 3-6 months.  
* **Operational Complexity:** ClickHouse requires careful tuning of partition keys, ordering keys, and materialized views for optimal performance. Teams need expertise in distributed database operations, including managing replication, sharding strategies, and cluster topology.  
* **Learning Curve:** Unlike UI-driven tools that abstract the query layer, leveraging the full power of ClickHouse requires proficiency in SQL. While this offers greater flexibility, it may require training for teams used to query languages like PromQL or Lucene. This can be mitigated by open source tooling such as HyperDX, which provides a rich visualization and exploration layer on top of ClickHouse as part of ClickStack. It offers Lucene-like query semantics that are transparently transpiled into efficient SQL, giving users a familiar search experience.  
* **Alternative Options:** For teams with under 100GB daily telemetry and simple alerting needs, managed services like Datadog may offer faster time-to-value despite higher per-GB costs. Additionally, if the primary use case is purely text search without aggregation, inverted-index systems like Elasticsearch remain highly effective.

## Proof at scale: The observability architectures of OpenAI, Anthropic, and Tesla

The benefits of this architecture are proven by its adoption in the most data-intensive environments where companies process petabytes of observability data daily. OpenAI rebuilt their observability platform on ClickHouse to achieve sub-second query performance on massive data throughput. Anthropic, developers of Claude, noted that with ClickHouse, "[queries are lightning-fast, and money is not on fire as much](https://clickhouse.com/comparison/splunk-for-observability)," referring to the significant cost reductions compared to their previous solution. Tesla validated this scale, choosing ClickHouse for their metrics platform because "Data in ClickHouse is better than data anywhere else. No other system lets you [slice and dice your data](https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse)... There's nothing out there that competes with ClickHouse."

## Conclusion: build your observability on the right foundation

These considerations aside, the fundamental shift in observability remains: it is now an analytics problem that requires an analytics-grade solution. The three-pillars model is obsolete. In 2026, observability is a unified analytics discipline. This shift makes the underlying database the critical architectural decision. An engine not built for analytics will inevitably struggle with the scale and complexity of modern systems.

ClickHouse provides a foundation engineered for high-performance analytics on granular, raw event data. It delivers the speed to explore "unknown unknowns" interactively and the cost-efficiency to store all data. As system complexity grows and observability costs compound, the limitations of siloed architectures become untenable. The question for most teams isn't whether to adopt an analytics-first approach. Instead, the question is how quickly they can migrate before costs and capability gaps become critical. Ready to build on the right foundation? **Get started with [ClickHouse Cloud](https://clickhouse.com/cloud) today.**  


What is observability in 2026? Why it's an analytics problem and why your database matters.

* **The problem:** New Relic's per-seat pricing (the "seat tax") punishes collaboration by making it expensive to give your whole team access to data. Its alternative consumption-based pricing model is ill-suited to observability, penalizing investigations and making costs highly unpredictable. Its proprietary query language, NRQL, creates vendor lock-in and a skills silo.  
* **The modern solution:** true observability requires democratized access. The best alternatives decouple pricing from user count and are built on open standards like [OpenTelemetry](https://opentelemetry.io/) and SQL, giving you ownership of your data and skills.  
* **Why a ClickHouse-based approach is the answer:** [observability solutions](https://clickhouse.com/resources/engineering/best-open-source-observability-solutions) built on the high-performance ClickHouse database offer a different, more open approach. They provide resource-based pricing for unlimited users and leverage standard SQL for querying, making observability scalable, cost-effective, and accessible to everyone.  
* **In this guide,** we evaluate 8 alternatives to New Relic, comparing them on user pricing, query language, and their ability to break you free from vendor lock-in.

> "Observability is a team sport, until the bill arrives." - Yours truly.

For many engineering organizations, New Relic is the default starting point. Its generous free tier is well known, but as startups mature into enterprises, the platform’s pricing structure often becomes a barrier. Engineering leaders are frequently forced into an uncomfortable position: deciding which engineers are "senior enough" to deserve a login, or risking unpredictable bills from "consumption" models that charge for every query. 

The hidden cost isn't on the invoice. It's the cost of exclusion. When junior developers, support agents, and product managers are locked out of data to save money, incident response slows, and knowledge becomes centralized among a small number of licensed users.

This guide explores 8 alternatives that break you free.

## **What are the hidden costs of New Relic's "walled garden"?**

New Relic is a robust, feature-rich platform that pioneered Application Performance Monitoring (APM). However, its architecture and business model were built for a previous era of software development where "monitoring" was the job of a specialized Ops team, not a shared responsibility across the entire organization.

### The pricing trap

[New Relic](https://newrelic.com/pricing) forces you to choose between different pricing models, neither of which aligns with customers' observability needs.

#### The "seat tax": punishing collaboration with per-user pricing

The defining struggle with New Relic is the distinction between "Basic" and "Full Platform" users. Modern observability relies on the idea that *anyone* should be able to query logs or trace a request to understand a bug. New Relic’s model penalizes this behavior. This model monetizes users, not data, incentivizing leaders to ration access. 

#### The “compute tax”: forcing users to restrict queries and actions

The alternative "[Core Compute](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/)" model removes seat limits but introduces **opacity in how consumption is billed**. They charge based on "Compute Capacity Units" (CCUs) - a proprietary metric used for actions such as refreshing a dashboard, loading a page, or running a query. As a result, users are forced to reduce their use of observability tools to avoid a huge bill. This model also adds friction to investigations because developers and SREs need to think about how they use the product while troubleshooting, especially during high-pressure incidents when the focus should be on resolving the issue rather than on tool costs. SREs should not be constrained as to how a product is used when resolving incidents.

#### The "intelligence" tax: penalizing AI workflows

As teams move toward AI-driven observability, New Relic has introduced a new cost vector: **Advanced Compute Units (aCCUs)**. Features such as predictive alerting and AI-assisted root cause analysis consume these premium units more frequently. This means the more you use modern AI tools to debug your system, the more you pay. The potential for AI agents to issue 10s, if not 100s of queries, makes this pricing model completely inappropriate, with the potential for unpredictable costs.

### **Vendor lock-in: the trap of a proprietary query language (NRQL)**

Proprietary languages like **NRQL** are dangerous precisely because they *look* like SQL, but they don't behave like it. While NRQL borrows keywords such as `SELECT` and `FROM`, it lacks the full power of standard SQL (e.g., complex joins and standard functions) and, most importantly, is **non-portable**.

Spending years mastering NRQL creates a "dead-end skill." You cannot migrate those queries to another tool, a data warehouse, or a business intelligence platform.

### **The "black box" problem: when you don't own your data**

New Relic operates as a black box. You send data through their agents and query it in their language. If you ever decide to leave, you realize that your dashboards, alerts, and team knowledge are non-portable. Open alternatives are shifting toward [**OpenTelemetry** for data collection](https://clickhouse.com/docs/observability/integrating-opentelemetry) and **using existing SQL skills** for querying. This "Open Architecture" ensures that you own your data pipeline and your team’s skills remain relevant regardless of the vendor.

## **The modern solution: an open, SQL-based observability platform**

### **Introducing the [ClickStack](https://clickhouse.com/use-cases/observability) model: built on ClickHouse**

The [ClickStack model](https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse) is a different philosophy from New Relic's. It's a model in which a high-performance data engine, ClickHouse, serves as the core, and an open-source visualization layer, such as [HyperDX](https://clickhouse.com/docs/cloud/manage/hyperdx), provides the user interface. 

Moving to an open engine doesn't mean sacrificing user experience. HyperDX provides an interface that rivals SaaS platforms like New Relic or Datadog.

* **Natural Language Querying:** Ask plain English questions about your logs and traces without SQL expertise. The system translates them into optimized queries.  
* **Correlated Traces and Logs:** Like New Relic, HyperDX lets you jump from a trace spanning multiple microservices directly to the relevant logs.  
* **Full SQL Power:** When you need more than the standard UI allows, you can use standard SQL to run complex aggregations that proprietary tools can't match.

Instead of buying "seats" in a SaaS application, you're using a powerful, open database. This architecture is designed to democratize observability. Because ClickHouse is a columnar database built for analytics, it is architecturally well-suited to the aggregation-heavy, high-cardinality queries common in observability, delivering excellent speed and cost efficiency.

Functionally, the ClickStack model replaces the proprietary NRQL with standard SQL. ClickHouse achieves its speed not just from its columnar storage format, but also from [**vectorized query execution**](https://clickhouse.com/docs/academic_overview)**, parallel processing across all available cores, and aggressive data skipping** enabled by its [sparse primary indexes](https://clickhouse.com/docs/primary-indexes) and data ordering. As OpenAI discovered, the performance is real: *“Previously, querying the last 10 minutes would take 1-2 minutes. With ClickStack, it was just a case of how fast I could blink."*

Because the pricing is based on the resources required to process your data, **users are free**. You can invite your entire engineering, product, and support teams to the platform without increasing your monthly spend by a cent. This approach supports modern DevOps goals, like shared responsibility. This model changes your observability strategy from 'what can we afford to sample?' to 'send everything and ask any question'.

This isn't just theory. Industry leaders are already using ClickHouse for observability at extreme scale. [Anthropic relies on ClickHouse to scale observability](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era) for developing models like Claude 3, noting that with ClickHouse, *'money is not on fire.'*

### **How this model solves New Relic's core problems**

| Friction point | The New Relic problem (the old way) | The ClickStack solution (the ClickHouse way) |
| :---- | :---- | :---- |
| **User pricing** | The "seat tax" ($349+/user) creates data gatekeepers and discourages team-wide access. | **Unlimited users.** Pricing is resource-based (compute/storage), not per-user. Everyone from junior devs to PMs gets access for free. |
| **Query language** | Insights are locked behind proprietary **NRQL**, a non-transferable skill that deepens vendor lock-in. | **Standard SQL for querying** is used for all queries. Your team uses existing skills on a high-performance database to run sub-second analytical queries on petabytes of data, ensuring knowledge is portable. |
| **Data ownership** | Data is trapped in a "black box." Dashboards, alerts, and knowledge are non-portable if you leave. | **You own your data.** Built on OpenTelemetry and an open-source database, your data pipeline and instrumentation are vendor-neutral. |
| **High cardinality** | Systems struggle and become expensive when handling high-cardinality data from sources such as containers or request traces. | **Built for high cardinality.** ClickHouse's columnar architecture is architected to handle high-cardinality data efficiently, **mitigating the typical performance degradation and significant cost increases** seen in traditional systems. |
| **Total cost (TCO)** | Bloated, monolithic agents and expensive data retention tiers drive up costs, often for features you don't use. | **High cost-efficiency.** Efficient compression (often >15x), the ability to use low-cost object storage, and the **separation of storage and compute** significantly reduce TCO. Pay only for the resources you use, not for redundant data storage. |

While a ClickHouse-based architecture presents a fundamental shift, other popular tools offer different trade-offs in solving New Relic's challenges.

## **How do other popular alternatives compare?**

We have selected these alternatives based on their ability to replace New Relic’s specific strengths (APM) while comparing them on key factors like user pricing, data ownership, and query language.

| Alternative | User pricing model | Query language(s) | OpenTelemetry support | Key differentiator |
| :---- | :---- | :---- | :---- | :---- |
| **ClickStack** | **Resource-based (unlimited users)** | **SQL** | Native/first-class | **New Relic-like UI/UX (HyperDX)** combined with the unmatched cost-efficiency of **resource-based pricing** and performance of ClickHouse. Unlimited users and deep analysis with SQL. |
| **Datadog** | Usage + user tiers | Proprietary (DSL) | Yes | Comprehensive infrastructure monitoring and deep integration across its own product ecosystem. |
| **Dynatrace** | Host / DDU | Proprietary (DQL) | Yes | AI-powered automation for root-cause analysis in complex enterprise environments. |
| **Grafana Stack** | Self-hosted / SaaS (usage) | [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/), LogQL, TraceQL | Yes | A flexible open-source, DIY stack for maximum control and unmatched visualization power. |
| **Splunk** | Ingest volume | Proprietary (SPL) | Yes (via Collector) | A security-first (SIEM) platform with powerful log search, often used for tool consolidation. |
| **Chronosphere** | Usage shaping | PromQL | Native / first-class | Tames high-cardinality metrics at massive scale by controlling data before ingestion. |
| **Signoz** | Usage / self-hosted | SQL-based (ClickHouse) | Native / first-class | An all-in-one platform that mimics New Relic UI/UX. Good for startups, but Cloud pricing is still volume-based (per GB). |
| **Dash0** | Usage | PromQL / SQL | Native / first-class | OTel-native backend that leverages ClickHouse and object storage for serverless simplicity. |

### **1. Datadog: for an infrastructure-first approach**

If New Relic is the king of APM (Code), [Datadog](https://www.datadoghq.com/) is the king of Infrastructure (Servers). For many teams, the "New Relic vs. Datadog" debate comes down to where your problems live.

* **The shift:** if your team is spending more time debugging Kubernetes clusters, microservices networking, and cloud infrastructure than distinct lines of code, Datadog’s infrastructure-first approach feels more intuitive than New Relic’s application-first view.  
* **Key considerations:** Datadog does *not* solve the cost issue. It just moves it. While you might save on "Seat" licenses (Datadog is generally more generous with user counts), you will likely pay more for custom metrics and host-based licensing.  
* **Best for:** teams migrating from a monolithic app (New Relic’s sweet spot) to a complex microservices architecture.

### **2. Dynatrace: for AI-powered, automated root-cause analysis**

[Dynatrace](https://www.dynatrace.com/) is often the choice for organizations that find New Relic too "manual." While New Relic provides tools for developers to query data, Dynatrace uses its "Davis" AI engine to identify issues automatically.

* **The shift:** this is for enterprises that want to move away from "dashboards" entirely. The "OneAgent" approach is less about developer curiosity and more about automated root-cause analysis.  
* **Key considerations:** It is arguably more expensive and more proprietary than New Relic. You are doubling down on the "Black Box" model, not escaping it.  
* **Best for:** large-scale, legacy enterprise environments where manual debugging is impossible due to complexity.

### **3. Grafana Stack: for a DIY, open-source approach**

For teams who resent the "SaaS Tax" entirely, the [Grafana](https://grafana.com/) ecosystem is the standard exit ramp.

* **The shift:** this is the "Build vs. Buy" alternative. New Relic sells you a service, while Grafana gives you the components to build it yourself. It offers the ultimate freedom in visualization. New Relic’s dashboards feel rigid and limited compared to what a skilled engineer can build in Grafana.  
* **Key considerations:** you trade subscription costs for operational costs. You are now responsible for the uptime of your monitoring stack.  
* **Best for:** engineering teams with strong OPS resources who value control and visualization above all else.

### **4. Splunk: for consolidating with a security-first platform**

Sometimes, the pressure to leave New Relic comes from the C-Suite asking to consolidate tools. [Splunk](https://www.splunk.com/) is often already in place for Security Information and Event Management (SIEM).

* **The shift:** Splunk is a log-centric platform. If your debugging workflow is 90% "searching massive log files" and only 10% "looking at APM traces," Splunk’s query power (SPL) is unmatched.  
* **Key considerations:** Splunk is generally not considered "developer-friendly" for APM. It is a heavy, complex tool that lacks the fluidity of New Relic’s trace visualization.  
* **Best for:** consolidating Observability and Security budgets into one massive contract.

### **5. Chronosphere: for taming high-cardinality metrics at scale**

[Chronosphere](https://chronosphere.io/) is a specialized tool that attacks the scaling limitations of Prometheus.

* **The shift:** New Relic can struggle with "high cardinality" metrics (custom tags). Chronosphere is designed to address this problem by enabling you to shape and aggregate data before it reaches the database.  
* **Key considerations:** It is highly focused on metrics and tracing. If you rely heavily on New Relic’s "Logs in Context," you may find Chronosphere’s logging capabilities less integrated.  
* **Best for:** cloud-native "Unicorns" who are scaling out of a DIY Prometheus setup.

### **6. Signoz: for an open-source, all-in-one experience**

[Signoz](https://signoz.io/) is the closest thing to an "Open Source New Relic." It mimics the UI and workflows of the major SaaS players but is built on Open Source ClickHouse.

* **The shift:** it offers a familiar feel for developers leaving New Relic (traces, metrics, and logs in one pane), but allows you to self-host or pay a much lower cloud rate compared to New Relic. It is an "application first" platform, meaning you interact with the SigNoz UI, not the database directly.  
* **Key considerations:** while the core features are there, it lacks the depth of New Relic’s 15 years of edge-case handling. Additionally, while its self-hosted option provides maximum control, it places the operational burden on your team. The managed Signoz Cloud offering, while convenient, may not match the architectural advantages of other managed ClickHouse services, such as the complete separation of storage and compute that optimizes costs for long-term data retention.  
* **Best for:** startups that want a cheaper, open-source version of New Relic but are comfortable with an ingest-based pricing model, rather than owning the data engine themselves.

### **7. Dash0: for a backend-only, OTel-native data lake**

[Dash0](https://www.dash0.com/) is for the "Serverless" generation. It is an observability data lake that is strictly OpenTelemetry native.

* **The shift:** New Relic requires setup, agent configuration, and index management. Dash0 aims to be invisible: you just point your OTel exporter at it, and it handles the rest. For visualization, it relies on the [CNCF project Perses](https://presentations.cncf.io/projects/perses/), ensuring your dashboards are standards-compliant and not tied to a proprietary vendor.  
* **Key considerations:** it is a newer player with a "bring your own dashboard" philosophy.  
* **Best for:** teams that want a "backend only" replacement for New Relic.

## **Conclusion: are you renting your data or owning it?**

When you choose an alternative to New Relic, you aren't just selecting a UI. You are choosing a philosophy.

Moving to a modern data warehouse model (ClickStack, Signoz) means asserting ownership. By standardizing on **OpenTelemetry** for ingestion and **the universal SQL standard** for analysis, you break down data silos. You allow every developer to access the system at no license fee, and you ensure your team's skills are transferable.

The future of observability isn't about better agents; it's about open data. And when that open data lives in a powerful analytical engine like ClickHouse, you can correlate system performance directly with business outcomes. This goal is impractical when observability and analytics are treated as separate silos.

Ready to own your data? The ClickStack model is powered by ClickHouse. Start a trial with ClickHouse Cloud today to build your own high-performance, cost-effective observability platform and see how much faster your team moves when everyone has access to the data.


Get started today

8 top New Relic alternatives to break the pricing trap (2026 guide)

Resource hub

Engineering

How to engineer cost-efficient open source observability with ClickHouse (ClickStack) - 2026 technical playbook

What is observability in 2026? Why it's an analytics problem and why your database matters.

8 top New Relic alternatives to break the pricing trap (2026 guide)