ClickHouse vs Datadog for observability data

Datadog and ClickHouse® solve different problems in the observability stack. Datadog is a managed platform that collects metrics, logs, traces, and infrastructure signals, then provides dashboards, alerting, and APM in a unified UI. ClickHouse is a columnar SQL database you operate (or use via a managed service) to store and query high-volume event data with arbitrary SQL.

Teams compare them when log volume grows, Datadog costs rise, or they need SQL access to raw observability data for custom dashboards and product features.

What Datadog provides

Datadog is an observability SaaS platform. Per Datadog's product documentation, it covers:

• Infrastructure monitoring for hosts, containers, and cloud resources
• Log management for centralized log ingestion, search, and retention
• APM for distributed tracing and service performance
• Dashboards and alerting with pre-built integrations for common stacks

Datadog handles collection agents, storage, indexing, UI, and alerting as one product. You configure integrations, write monitors, and query through Datadog's interfaces rather than raw SQL over your own storage layer.

What ClickHouse provides

ClickHouse is an OLAP database for storing and querying event data at high volume. Per ClickHouse documentation, it provides:

• Columnar storage optimized for analytical scans and aggregations
• SQL query interface with arbitrary GROUP BY, window functions, and joins
• High write throughput for continuous log and metric ingestion
• Configurable retention via TTL and tiered storage

ClickHouse does not ship agents, pre-built APM views, or a turnkey alerting UI. You bring ingestion (Vector, Fluent Bit, Kafka, OpenTelemetry collectors), define schemas, write queries, and connect dashboards or alerting systems to the results.

Architecture comparison

Datadog optimizes for time-to-value: install the agent, get dashboards. ClickHouse optimizes for query flexibility and storage efficiency at scale: you own the schema and SQL, you control retention and cost.

Log and metric query patterns

Datadog Log Explorer filters logs by facets, time range, and full-text search. The query model is optimized for interactive exploration and issue grouping.

ClickHouse stores logs as rows in a MergeTree table and queries them with SQL:

CREATE TABLE logs
(
    ts          DateTime64(3),
    service     LowCardinality(String),
    level       LowCardinality(String),
    message     String,
    trace_id    String
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (service, level, ts);

SELECT
    toStartOfMinute(ts) AS minute,
    service,
    countIf(level = 'ERROR') AS errors
FROM logs
WHERE ts >= now() - INTERVAL 1 HOUR
GROUP BY minute, service
ORDER BY minute;

For real-time logs analytics architectures, ClickHouse handles large log tables efficiently when the sort key aligns with filter columns.

Metrics follow the same pattern. Datadog stores and charts metrics natively. ClickHouse stores metric samples as time-series rows and aggregates with SQL or pre-computed materialized views.

Cost model differences

Datadog pricing is published on datadoghq.com/pricing. Plans combine per-host fees, per-ingested-volume charges for logs and custom metrics, and feature-tier add-ons. Costs scale with infrastructure footprint and event volume.

ClickHouse costs depend on deployment model: self-hosted infrastructure, ClickHouse Cloud consumption, or a platform like Tinybird. You pay for compute and storage you provision or consume, not per host or per indexed log line in a proprietary format.

At high log volume, teams often hit a tradeoff: Datadog's integrated experience versus the storage efficiency and query flexibility of keeping raw events in ClickHouse. For real-time error monitoring, the break point often comes when arbitrary SQL over raw error streams matters more than issue-grouping UI.

When Datadog is the better fit

Choose Datadog when:

• You want a single platform for metrics, logs, traces, and APM without building pipelines
• Your team needs out-of-the-box dashboards and monitors for standard infrastructure
• Operational overhead of running a database cluster is not acceptable
• Log volume and host count fit within your observability budget

Datadog reduces time-to-detection for teams that prioritize integrated tooling over SQL flexibility.

When ClickHouse is the better fit

Choose ClickHouse when:

• Log and metric volume makes SaaS observability pricing unsustainable
• You need arbitrary SQL analytics over raw events, not predefined facets
• Observability data powers customer-facing features, not just internal ops
• You want multi-month retention with columnar compression efficiency
• You already run Kafka or OpenTelemetry and need a query engine downstream

ClickHouse fits the storage and query layer. Collection and alerting remain your responsibility or integrate via tools like Grafana and PagerDuty.

Hybrid architecture

Many teams use both: Datadog for day-to-day ops monitoring and alerting, ClickHouse for long-retention SQL analytics and product-facing observability features.

Apps → Datadog Agent → Datadog (ops dashboards, alerts)
Apps → Vector/Kafka → ClickHouse/Tinybird (SQL analytics, APIs)

For teams that built a Datadog alternative with ClickHouse, the Logs Explorer template pattern shows how ClickHouse plus a web UI covers log search and dashboards without Datadog's per-volume pricing model.

For real-time anomaly detection, ClickHouse stores metric history and SQL endpoints evaluate thresholds on fresh data.

For ClickHouse cybersecurity logs, the same SQL-over-events model applies to security event correlation across sources.

Tinybird as the ClickHouse observability layer

Building observability on raw ClickHouse means managing ingestion, schema evolution, cluster operations, and API generation. Tinybird is managed ClickHouse with a hosted ingestion layer, hosted API layer, and developer tooling so you can ship observability analytics without owning the infrastructure.

The observability workflow on Tinybird:

1. Ingest observability event data via the Events API or Kafka connector.
2. Define Data Sources with sort keys aligned to service, level, and ts.
3. Write SQL Pipes for error rates, latency percentiles, and log search.
4. Publish Pipes as sub-second API endpoints for Grafana, Tinybird Charts, internal tools, or customer-facing UIs.

For build dashboards with real-time data interaction, Tinybird endpoints power ops dashboards with the same SQL flexibility as raw ClickHouse without cluster management.

Resend processes 100TB per month on Tinybird with 62ms p90 query latency without relying on cache, per Tinybird's Resend customer story. Tinybird is SOC 2 Type II certified.

What the choice comes down to

Datadog is an observability product. ClickHouse is a database for observability data. Datadog wins on integrated collection, UI, and alerting out of the box. ClickHouse wins on SQL flexibility, storage efficiency, and cost predictability at high event volume.

Teams that need both often keep Datadog for ops and add ClickHouse via Tinybird when log analytics outgrows SaaS pricing or needs to surface in product APIs.