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

* **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.

Summary

> "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.

Frequently asked questions

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)

* **The problem:** Datadog's unpredictable and high costs are not just a pricing issue. They are a symptom of an architecture that scales with high-cardinality data by passing significant costs on to the user. This leads to expensive custom metrics, dual charges for ingestion and querying, and penalties for dynamic infrastructure.  
* **The solution is architectural:** The most effective alternative isn't just a cheaper tool but one built on a modern columnar data engine designed for analytics at scale. Solutions like ClickStack, built on the ClickHouse columnar database, are designed specifically for the speed and scale that modern observability demands.  
* **ClickStack's advantage:** By unifying logs, metrics, and traces in a single high-performance datastore, ClickStack delivers sub-second queries on petabytes of data, high [data compression](https://clickhouse.com/blog/cost-predictable-logging-with-clickhouse-vs-datadog-elastic-stack) (14x), and a simple, predictable pricing model. It solves the high-cardinality problem natively, offering massive [cost savings](https://clickhouse.com/blog/building-a-logging-platform-with-clickhouse-and-saving-millions-over-datadog) and performance gains over traditional platforms.  
* **This guide:** We compare eight alternatives, focusing on their underlying architecture, pricing models, and ability to handle high-cardinality data, helping you choose a solution that scales without surprise bills.


TL;DR

It’s a familiar story for many DevOps teams: the monthly observability bill is spiraling out of control. When a [Hacker News thread](https://news.ycombinator.com/item?id=35837330) about a single company's $65 million Datadog bill went viral, it unleashed a wave of similar complaints about complex, unpredictable billing. But these high costs are symptoms of a deeper architectural problem. Many legacy platforms were not built for the reality of modern systems, which generate huge volumes of high-cardinality data from [ephemeral infrastructure like Kubernetes](http://thesystemguide.com/high-cardinality-kubernetes-monitoring). This mismatch leads to punitive fees for custom metrics and dual charges for ingestion and querying. This guide provides a technically-grounded comparison of alternatives, focusing on the core architecture that solves these fundamental problems of performance and cost at scale.

## **Why Datadog's pricing model struggles at scale**

Datadog is a powerful platform, but its pricing model can lead to unpredictable and escalating costs, especially for organizations operating at scale. These financial pressures are not arbitrary. They are symptoms of an architecture that, while capable, becomes prohibitively expensive when applied to the high-volume, high-cardinality data that defines modern observability.

Here’s a breakdown of the key challenges:

| Challenge | Description | Architectural cause |
| :---- | :---- | :---- |
| **The high-cardinality tax** | Exploding costs for custom metrics when adding tags with many unique values (e.g., `container_id`, `customer_id`). | Traditional indexing technology struggles to efficiently manage and query a vast number of unique metric time series. |
| **The ingestion vs. query penalty** | Paying once to ingest logs and a second, higher fee to index them for querying, forcing teams to limit what they analyze. | Data is stored in a way that is not optimized for fast, ad-hoc analytical queries without expensive, upfront indexing. |
| **The per-host problem** | Costs for APM and infrastructure are tied to the number of hosts, penalizing modern, ephemeral architectures like Kubernetes. | A billing model tied to a legacy unit (hosts) that fails to represent modern, container-based workloads where host counts are dynamic and often irrelevant. |

### **The high-cardinality tax**

A primary driver of surprise bills is the "custom metric tax." Datadog's billing for custom metrics is based on cardinality: the number of unique combinations of a metric name and its tags (e.g., `host`, `customer_id`, `container_id`). Adding a single tag with many unique values, a common practice when using frameworks like OpenTelemetry, can cause the volume of billable metric time series to explode. At scale, custom metrics can account for over half of a total Datadog bill. This occurs because traditional monitoring systems often rely on indexing technologies that struggle to efficiently manage and query a vast and ever-growing number of unique label combinations.

### **The ingestion vs. query penalty**

For log management, Datadog uses a dual-cost model that charges teams twice for the same data. You first pay an ingestion fee simply to collect and process the logs (e.g., $0.10 per GB). To make those logs searchable and useful for real-time debugging, you must pay a second, much higher fee to *index* them for analysis (e.g., $1.70 per million log events). This creates a difficult choice between budget and visibility, forcing engineering teams to be highly selective about what data they can afford to analyze, undermining the goal of comprehensive observability.

### **The per-host problem**

Finally, tying core service costs for infrastructure monitoring and APM to the number of hosts penalizes modern, dynamic architectures. In environments like Kubernetes, where containers and nodes are ephemeral and scale on demand, the "per-host" metric is a fluctuating, unpredictable multiplier for costs.

This model forces teams into a highly undesirable trade-off: either compromise their architecture to minimize billable hosts — prioritizing cost over resilience — or accept "[observability gaps](https://clickhouse.com/resources/engineering/managing-petabyte-scale-logs-without-sampling)" by leaving services unmonitored to stay within budget.

## **The 8 best Datadog alternatives for scalable observability**

This table provides a quick summary of the 8 alternatives discussed below, helping you identify the best potential fits based on your primary needs and technical preferences.

| Alternative | Core architecture | Best for high cardinality? | Primary strength | Best for |
| :---- | :---- | :---- | :---- | :---- |
| **ClickStack** | Unified columnar database | Yes, natively | Excellent cost & performance at scale | Teams needing to solve high-cardinality issues and drastically cut observability costs. |
| **New Relic** | Proprietary SaaS | No, can be costly | Deep APM insights | Enterprises needing mature, all-in-one APM without strict budget constraints. |
| **Dynatrace** | Proprietary SaaS / OneAgent | No, can be costly | AI-powered automation | Large enterprises needing powerful, automated root-cause analysis in complex environments. |
| **Grafana Stack** | Siloed (Loki, Mimir, Tempo) | Yes, but complex | Open source & customizable | Teams invested in the Prometheus ecosystem with resources to manage operational complexity. |
| **Splunk** | Search index | No, struggles at scale | Log management & SIEM | Enterprises focused on deep log analysis and security, with significant budgets. |
| **Chronosphere** | Cloud-native SaaS (M3) | Yes, via control plane | Traffic shaping & Cost control | Large cloud-native organizations struggling with Prometheus scale and costs. |
| **Signoz** | Open-source (ClickHouse) | Yes, natively | Unified OSS experience | Teams wanting an open-source, self-hostable Datadog alternative. |
| **Dash0** | Serverless OTel Data Lake | Yes | OTel-native & Serverless | Teams fully committed to OpenTelemetry seeking zero ops. |

### **1. ClickStack (on ClickHouse)**

For teams grappling with the architectural limitations and prohibitive costs of Datadog, ClickStack offers a fundamentally different approach. ClickStack treats observability as a data problem—one best solved by combining a highly efficient data engine with a universal data standard. Built on the open-source, columnar database ClickHouse and the industry-standard OpenTelemetry framework, it is an end-to-end solution comprised of high-performance storage and a purpose-built UI from HyperDX. This stack is designed from the ground up for high performance, cost-efficiency, and total data portability.

The architecture centers on a unified datastore for logs, metrics, and traces. By strictly adhering to the OpenTelemetry data model, ClickStack eliminates data silos and stores telemetry as 'wide events' (structured rows containing all context). This OTel-native structure is uniquely suited for ClickHouse’s columnar format, enabling blazing-fast aggregations. Because ClickHouse combines vectorized query execution with multi-core parallel processing, it can process these structured OTel spans with sub-second query times, even on petabytes of data.

Crucially, ClickStack represents a shift away from proprietary agents. As a deeply OpenTelemetry-native platform, it decouples your instrumentation from your backend. Unlike proprietary vendors that lock your code into their specific libraries, ClickStack leverages OTel to ensure you own your data generation. By supporting standard query languages like SQL alongside standard OTel semantic conventions, ClickStack empowers teams to practice "Observability Science": performing deep, ad-hoc analysis to correlate system behavior with business outcomes in a way that is impossible with proprietary DSLs.

**Key features:**

* Unified columnar datastore: Ingests and analyzes OTel logs, metrics, and traces in a single, high-performance database.  
* OpenTelemetry native: Built entirely on the OTel standard to prevent vendor lock-in, ensuring you never have to re-instrument your code to switch tools.  
* Sub-second query performance: Delivers blazing-fast aggregations on high-cardinality OTel attributes.  
* High data compression: Achieves industry-leading data compression of over 15x, dramatically reducing storage costs.  
* Full SQL support: Enables deep, ad-hoc analysis beyond the limitations of pre-built dashboards.

**Pros:**

* Future-proofs instrumentation via OpenTelemetry: ClickStack removes the risk of vendor lock-in at the source. By standardizing on OpenTelemetry for ingestion, you control the "edge" of your observability pipeline.  
* Solves the high-cardinality aggregation problem: ClickHouse is designed to handle these aggregations significantly better than alternatives. It allows teams to process high-cardinality OTel tags efficiently on disk or leverage Materialized Views.  
* Fast, efficient performance: ClickHouse's columnar design enables high data compression (often exceeding 15x) and fast queries using data skipping via sparse primary indexes.  
* Cheap, long-term retention on object storage: Running on ClickHouse Cloud separates storage and compute, allowing you to retain full-fidelity OpenTelemetry data for months or years on low-cost object storage.  
* Excellent cost-efficiency at scale: For internal observability workloads, this stack has been found to be up to [200x more cost-effective](https://clickhouse.com/blog/building-a-logging-platform-with-clickhouse-and-saving-millions-over-datadog) than Datadog.  
* Predictable, transparent pricing: Operates on a simple compute-plus-storage model, eliminating complex SKUs and punitive taxes like per-host charges.  
* Flexible & Interoperable: Built on a fully open-source (Apache 2.0) foundation, allowing teams to integrate existing data pipelines using popular agents like Vector and FluentD.

**Cons:**

* Emerging UI and ecosystem: As a newer solution, the ecosystem of out-of-the-box integrations is still growing compared to established vendors.  
* Advanced features in development: Features like native UI-based RBAC and sophisticated alerting are still on the roadmap.  
* Best for SREs and developers: The platform is optimized for SREs and developers comfortable with SQL and OTel concepts rather than general BI workflows.

**Best for:**

* Cost-conscious organizations operating at a large scale.  
* Engineering teams who want to standardize on OpenTelemetry to own their observability data.  
* Teams struggling with high-cardinality data in Elasticsearch or Prometheus.  
* Users looking to migrate from expensive logging solutions like Splunk or Datadog.  
* Organizations that want to unify their observability and business analytics in a single platform.

### **2. New Relic**

As a long-standing leader in the APM space, [New Relic](https://newrelic.com/) offers a mature, all-in-one observability platform. It combines application, infrastructure, browser, and log monitoring into a single solution, providing teams with a unified view of their entire stack.

* **Key features:** Comprehensive Application Performance Monitoring (APM 360), real-user monitoring (RUM), infrastructure monitoring, and an AI-powered alerting engine.  
* **Pros:** Established, feature-rich platform praised for its powerful APM capabilities. The alerting system is considered accurate and reliable.  
* **Cons:** High cost and a complex, user-based pricing model that penalizes growing teams. Some users also note challenges with dashboard configurations and Kubernetes integrations.  
* **Best for:** Enterprise teams that require a mature, consolidated platform with deep APM insights and are less constrained by budget.

### **3. Dynatrace**

[Dynatrace](https://www.dynatrace.com/) is an enterprise-focused observability platform known for its powerful AI capabilities and automated full-stack monitoring. Its core strength lies in the "OneAgent" technology, a single agent deployment that automatically discovers and maps all components and dependencies.

* **Key features:** AI-powered engine (Davis), full-stack monitoring (RUM to code-level), automated topology mapping (Smartscape), and digital experience management.  
* **Pros:** Strong automation and AI-driven root cause analysis simplify complex problem detection. The unified OneAgent simplifies deployment.  
* **Cons:** High cost and complex pricing model. The "OneAgent" can be resource-intensive, and the platform has a steep learning curve.  
* **Best for:** Large enterprises with complex, dynamic cloud environments that need powerful, AI-driven automation.

### **4. Grafana Stack (Loki, Mimir, Tempo)**

The [Grafana](https://grafana.com/) LGTM (Loki, Grafana, Tempo, Mimir) stack is a [popular open-source observability solution](https://medium.com/@achanandhi.m/why-do-you-need-to-use-grafana-and-loki-e0471c530083) made up of distinct, specialized components. Grafana serves as the central visualization platform.

* **Key features:** Loki (efficient log aggregation), Mimir (scalable metrics storage), Tempo (distributed tracing), and Grafana (visualization).  
* **Pros:** Cost-effective label-based indexing, open-source flexibility, and a unified visualization interface.  
* **Cons:** High operational complexity (managing multiple stateful systems), correlation happens at the application layer rather than the data layer, and data remains siloed.  
* **Best for:** Teams already committed to the Prometheus/Grafana ecosystem who prefer self-managed solutions and have the resources to handle complexity.

### **5. Splunk**

[Splunk](https://www.splunk.com/) is a powerful and long-standing platform known for its capabilities in searching, analyzing, and visualizing machine-generated data. It is a staple in many enterprise IT operations for log management and SIEM.

* **Key features:** Powerful Search Processing Language (SPL), real-time visibility, high scalability, and extensive integrations.  
* **Pros:** Market leader in log management, strong security (SIEM) features, and highly customizable.  
* **Cons:** Prohibitive cost at scale (especially for ingest-heavy workloads), poor query performance for complex analytics compared to columnar stores, and a steep learning curve.  
* **Best for:** Large enterprises with significant budgets prioritizing deep log analysis and security use cases.

### **6. Chronosphere**

[Chronosphere](https://chronosphere.io/) is a cloud-native observability platform built for high-scale environments. It leverages the open-source M3 metrics engine to handle massive amounts of high-cardinality data.

* **Key features:** Control Plane (shape/filter data before storage), scalable Prometheus backend (M3 based), and distributed tracing integration.  
* **Pros:** Effectively tames high cardinality via traffic shaping and offers cost predictability.  
* **Cons:** Relies on data dropping/aggregation to control costs (losing fidelity), metrics-heavy heritage with less mature logging, and enterprise-focused pricing.  
* **Best for:** Large, cloud-native organizations struggling with Prometheus scaling limits and needing strict control over metric growth.

### **7. Signoz**

[Signoz](https://signoz.io/) is an open-source APM and observability platform that positions itself as a direct, self-hostable alternative to Datadog. It is powered by Open Source ClickHouse.

* **Key features:** Unified UI (metrics, traces, logs), native OpenTelemetry support, and a ClickHouse backend.  
* **Pros:** Open-source freedom (self-hostable), cost-effective compared to SaaS, and an all-in-one "Datadog-like" experience.  
* **Cons:** Operational overhead for self-hosting and feature maturity compared to giants like New Relic. Critically, the self-hosted version lacks native separation of storage and compute. This results in three key inefficiencies: an inability to isolate read and write workloads, limitations on scaling to petabyte levels, and a lack of cost-efficient long-term retention on object storage.  
* **Best for:** Engineering teams wanting a unified, open-source solution or needing to leverage ClickHouse's efficiency without building a UI.

### **8. Dash0**

[Dash0](https://www.dash0.com/) is a newer entrant built on ClickHouse Open Source similar to Signoz. It positions itself as a serverless, OpenTelemetry-native observability data lake, focusing on "Observability as Code."

* **Key features:** Serverless architecture, dashboarding via Perses/Grafana, and direct OTel ingestion.  
* **Pros:** Zero maintenance (no backend management), no indexing costs, and strong OTel alignment.  
* **Cons:** Per-event pricing can punish verbosity during incidents, "headless" visualization creates a disjointed workflow, and the platform is still in early stages.  Additionally, it shares the architectural limitations of standard open-source ClickHouse: lacking full separation of storage and compute and requiring data to be duplicated in object storage in order to scale compute beyond vertical limits. This design limits performance when querying older data stored in colder tiers for larger workloads.
* **Best for:** Teams fully committed to OpenTelemetry who want a low-ops, serverless backend and are comfortable building their own visualizations.

## **Comparison summary table: finding the right fit**

| Alternative | Pricing model | Architecture | Instrumentation & OTel | Best for high cardinality? | Unified datastore? | Cost at scale |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| **ClickStack** | Resource-based (compute + storage) | Unified columnar database | Native OTel (schema designed for OTel) | Yes, natively | Yes (logs, metrics, traces) | Very low & predictable |
| **New Relic** | User-based, ingest-based | Proprietary SaaS | Full OTel support; proprietary agent optional | No, can be costly | Yes | High |
| **Dynatrace** | Host-based / "Davis Data Units" | Proprietary SaaS / OneAgent | OTel compatible; OneAgent required for AI | No, can be costly | Yes | Very high |
| **Grafana** | Resource-based (self-hosted) | Siloed (Loki, Mimir, Tempo) | Prometheus & OTel native | Yes, but complex | No (separate backends) | Low (high ops cost) |
| **Splunk** | Ingest-based / "Splunk units" | Search index | OTel for APM; proprietary for logs | No, struggles at scale | Primarily logs/SIEM | Very high |
| **Chronosphere** | Usage-based / shaped | Cloud-native SaaS (M3) | OTel compatible; Prometheus native | Yes, via control plane | Primarily metrics/traces | High (enterprise) |
| **Signoz** | Usage-based / Free OSS | OSS ClickHouse | Native OTel | Yes, natively | Yes | Moderate (No cost-efficient long-term retention) |
| **Dash0** | Usage-based | Serverless OTel Data Lake on OSS ClickHouse | Native OTel | Yes | Yes | Moderate (No cost-efficient long-term retention) |

## **Conclusion**

The search for a Datadog alternative often begins with sticker shock, but the real solution is found in architecture. As data volumes and cardinality continue to explode, platforms built on a search index or siloed backends will inevitably pass their scaling costs on to you. The key advantage of a unified, columnar data engine is that it treats massive-scale analytics as a native feature, not a billing problem. ClickStack, powered by ClickHouse, represents this modern approach, offering a path to deep, powerful observability without the false choice between cost and comprehensive visibility.

Ready to see what performance at scale feels like? [Start a trial](https://clickhouse.com/) with ClickHouse Cloud today, or read our [case study](https://clickhouse.com/user-stories) to see how high-volume teams are reducing costs by moving to a columnar engine.

The 8 best Datadog alternatives for observability at scale in 2026

* The problem: Aggressive log sampling, often necessitated by the scaling costs of legacy platforms, creates visibility gaps. You risk missing critical errors needed to solve outages and affecting the statistical integrity of your data.  
* The cause: Engineers typically rely on separate stacks for search (ELK) and trends (Prometheus). As data grows, neither scales efficiently for the other’s workload, forcing teams to sample logs to control costs.  
* The solution: OpenTelemetry provides the universal standards and semantic conventions required to break down the silos between logs, metrics, and traces. When this unified, OpenTelemetry-standard data needs to be stored at scale, modern columnar architectures are the solution. By using ClickHouse, teams benefit from 10-20x compression and a cloud-native design that separates compute from cost-efficient object storage. The ClickStack (the ClickHouse Observability Stack) embodies this architecture to help reduce trade-offs.  
* The proof: Engineering teams are achieving petabyte-scale ingestion and real-time analysis on 100% of their observability data, moving away from sampling to gain complete visibility without a runaway budget.

TL;DR: minimizing the need for log data compromise

## **Introduction: the scaling compromise**

As infrastructure scales into the petabytes, observability costs often follow a steep upward trajectory. To keep budgets under control, engineers are frequently advised to accept a difficult compromise: aggressive sampling.

Historically, engineers have relied on separate stacks to manage this data: search-based tools (like ELK) to isolate specific errors, and metric stores (like Prometheus) to monitor system health. Sampling became the primary survival mechanism to keep these distinct architectures affordable.

However, this compromise is a symptom of using legacy tools at a scale they were not designed for. The choice between complete visibility and a manageable budget does not have to be binary. In practice, sampling introduces risks that create critical blind spots.

### **You risk losing the "needle in the haystack"**

The most immediate risk is missing the low-frequency, high-severity event you didn't know you needed to look for. Critical system failures are often outliers: a single corrupt transaction, a slow API call causing tail latency, or a novel security threat. Aggressive sampling statistically increases the likelihood of discarding these exact events. By definition, it is difficult to write a sampling rule for an "unknown unknown" error you have never seen before. When a major outage occurs, the log line containing the root cause may have been dropped.

### **You compromise data integrity**

Beyond missing rare events, sampling can skew the statistical integrity of your data. When a percentage of telemetry is discarded, analytics become approximations. For example, sampling-based systems can under- or overestimate crucial metrics, such as duration, rendering percentile-based SLOs and trend analyses less reliable. This makes it difficult to accurately measure the true impact of minor issues or perform forensic analysis after a security incident.

### **You create operational complexity**

Maintaining complex sampling rules creates a significant operational task. Engineers must constantly adjust sampling configurations as applications evolve and new services come online. The criteria for what constitutes a "low-value" log today could be the critical signal for tomorrow's outage, requiring engineers to engage in a reactive cycle of adjusting rules.

| Risk category | Description | Business impact |
| ----- | ----- | ----- |
| Missing critical events | Low-frequency but high-severity events ("unknown unknowns") are statistically likely to be dropped by sampling rules. | Increased Mean Time to Resolution (MTTR) during major outages; missed security threats from unusual sources. |
| Compromised analytics | Discarding data skews metrics, making percentile-based SLOs, trend analysis, and capacity planning less reliable. | Inaccurate performance measurements; reduced trust in dashboards; difficult resource allocation and decision-making. |
| Operational complexity | Engineers must constantly create, manage, and update complex sampling rules as services and applications evolve. | Engineering resources spent on reactive infrastructure management; risk of human error leading to data loss. |

## **The architectural shift: unifying search and trends**

For years, sampling was a reaction to the architectural boundaries of available tools. We relied on search engines (Splunk, Elastic) that excelled at finding a specific error message but were less efficient at high-level aggregations and trends. Conversely, we used metric stores (Prometheus) that were excellent for trends but lacked the context of the raw event.

Modern OLAP databases eliminate this trade-off by excelling at both fast aggregations and high-speed filtering. ClickStack, the ClickHouse Observability Stack, embodies this architecture to provide an end-to-end, open-source solution. It allows engineers to see high-level trends and quickly drill down to the raw logs without jumping between tools.

The solution starts with open, vendor-neutral data collection via OpenTelemetry. OpenTelemetry acts as the critical bridge, providing the shared semantic conventions that allow you to seamlessly correlate logs with metrics and traces. From there, ClickStack uses ClickHouse as the scalable storage and analytics engine, and HyperDX as a purpose-built UI.

### **From storage overhead to efficient analytics**

Legacy platforms often face two challenges at scale: storage overhead and query performance. The first is a significant "indexing overhead." Reliance on inverted indexes for search creates storage requirements that can grow larger than the raw data itself. It's not uncommon for an initial 3GB of logs to [consume 30GB of disk space](https://stackoverflow.com/questions/27972246/elasticsearch-index-much-larger-than-the-actual-size-of-the-logs-it-indexed) in an Elasticsearch cluster.

The second challenge is analytical performance. While effective for search, inverted index architectures can struggle with the large-scale aggregations needed for observability. In contrast, ClickHouse is built for analytics. It uses lightweight [sparse primary indexes](https://clickhouse.com/docs/guides/best-practices/sparse-primary-indexes) on data that is physically sorted on disk. When you query a time range, ClickHouse uses this index to skip reading vast blocks of data. This I/O reduction is combined with a vectorized execution engine that processes data in batches and massively parallel processing that uses available CPU cores.

### **From row-oriented storage to columnar compression**

Traditional platforms are often row-oriented, storing all values for a single log event together. ClickHouse uses a columnar format, storing all values for a single column (e.g., all timestamps, all service names) together. This structure is highly effective for compression, creating results that routinely achieve [10-20x compression](https://clickhouse.com/resources/engineering/database-compression) ratios.

A common trade-off with columnar stores has been handling messy, semi-structured logs efficiently. ClickHouse addresses this with its native [JSON data type](https://clickhouse.com/blog/a-new-powerful-json-data-type-for-clickhouse). This feature offers the performance of a defined schema with the flexibility of a document store.

The JSON data type works by dynamically analyzing the data structure:

* Optimized column generation: It automatically identifies the most frequent properties and creates dedicated, optimized columns for them.  
* Long-tail bucketing: Rare or "long-tail" properties are bucketed into a generic store to prevent "column explosion," which effectively balances write performance with query speed.  
* Native types: Integers stay integers and aren't lazily cast to strings, maintaining high query performance.

*Note: While this simplifies ingestion significantly, it does require engineers to consider query patterns. Accessing the dedicated columns is faster than querying the "long-tail" bucket, meaning schema design still matters for optimal performance on your most frequent queries.*

This efficiency applies not just to logs, but also to high-volume traces and high-cardinality metrics. To further bridge the gap between metrics and logs, ClickHouse is actively working on PromQL support, which will allow engineers to bring their existing Prometheus queries and dashboards directly to ClickHouse without rewriting logic.

### **From coupled architecture to decoupled storage and compute**

Legacy systems often couple storage and compute resources. In these systems, storage and compute are tightly linked, forcing you to scale expensive servers just to retain more data. In contrast, ClickHouse was [designed for the cloud](https://www.slideshare.net/slideshow/clickhouse-at-cloudflare-by-marek-vavrusa/79778005), using cost-efficient and scalable [object storage](https://blog.cloudflare.com/log-analytics-using-clickhouse/) like Amazon S3 or Google Cloud Storage. This decouples storage from compute, allowing you to retain 100% of your data at a lower cost while scaling compute resources independently.

## **Proof in production: handling massive scale**

This architectural shift is becoming the standard for companies operating at the largest scale.

Cloudflare, which helps secure and accelerate a significant portion of the internet, was an [early adopter of ClickHouse](https://blog.cloudflare.com/log-analytics-using-clickhouse/). Their previous Elasticsearch-based pipeline struggled with ingestion limitations when faced with millions of requests per second. The ingestion rate limited their ability to query data in real-time. By migrating to ClickHouse, they removed these ingestion bottlenecks. The engineering outcome was the ability to query across massive datasets with low latency, powering critical systems like firewall analytics.

More recently, Anthropic required an architecture capable of ingesting [semi-structured data](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era) in real time to support their Claude AI models. When the Claude 3 and 3.5 models saw explosive user adoption, their existing observability systems faced scaling friction. With ClickHouse, Anthropic can now affordably store and instantly query 100% of their log data. The system is robust enough that engineers report they "sometimes don't even notice that the database is running."

| Company | Challenge | Solution with ClickHouse | Key outcome |
| ----- | ----- | ----- | ----- |
| Cloudflare | Previous pipeline struggled with ingestion throughput and resource efficiency at millions of logs per second. | Migrated logging pipelines to a self-managed ClickHouse cluster for superior ingestion speed and compression. | Petabyte-scale real-time analysis. Engineers can grep through massive datasets in seconds, enabling faster debugging and reliable customer analytics. |
| Anthropic | Existing systems faced scaling friction due to the data volume generated by Claude AI models. | Deployed ClickHouse to ingest and analyze 100% of their log data in real-time within their secure environment. | Full data retention at scale. Enabled deep model insights and robust debugging without requiring data sampling. |

## **Conclusion: stop sampling, start analyzing**

The trade-offs regarding log sampling have shifted. The practice of sampling was largely a workaround for the architectural limitations of search-based platforms and the separation of "search" and "metrics" tools. Storing 100% of your data is becoming the strategic standard for modern engineering teams.

A modern columnar platform like ClickStack, built on ClickHouse, changes the relationship between cost and performance. By decoupling compute from cost-efficient object storage and using 10-20x compression, it is economically feasible to retain petabytes of data. This architecture provides the visibility to find any "needle in the haystack," accurately analyze trends, and reduce the risk of missing the one critical event that explains a major outage.

It's time to move beyond the choice of sampling and start analyzing everything.

Ready to see for yourself? [Start a free ClickHouse Cloud trial](https://clickhouse.com/cloud) to experience petabyte-scale analytics firsthand. You can also [read our case studies](https://clickhouse.com/user-stories) with companies like Anthropic and Cloudflare who manage massive-scale observability with ClickHouse.

Resource hub

Engineering

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

The 8 best Datadog alternatives for observability at scale in 2026

Beyond sampling: managing petabyte-scale logs without losing data