OpenObserve Docs
OverviewComparison with alternatives

OpenObserve as a Datadog Alternative

Datadog is a capable, polished observability platform. For teams running at scale, the per-host pricing, the per-custom-metric fees, and the proprietary agent/format combo are the most common reasons to look at alternatives. This page summarizes how OpenObserve compares.

If you're ready to plan a migration, see the Datadog to OpenObserve Migration Guide for step-by-step instructions covering metrics, traces, logs, dashboards, and monitors.

Why Teams Consider Moving Off Datadog

Per-host pricing

Datadog's Infrastructure tier bills per host per month, with separate per-host fees for APM and other products. A few hundred hosts becomes a sizeable monthly invoice before any data volume is considered.

OpenObserve has no per-host fee. Pricing is ingest-based only. Doubling your host count without changing telemetry volume doesn't change cost.

Custom metrics fees

Datadog charges per custom metric (above the included quota). The fee is small per metric but multiplies quickly across high-cardinality services. Teams routinely rein in instrumentation to dodge metric-count overage.

OpenObserve includes unlimited custom metrics. There is no per-metric line item.

Vendor lock-in

Datadog's wire formats (the Agent HTTPS API, DogStatsD, the APM trace intake, the log intake) are proprietary. Once you've built dashboards, monitors, and integrations against them, the switching cost feels high.

OpenObserve speaks open protocols end to end: OpenTelemetry (OTLP) for all signals, plus Prometheus Remote Write, Loki Push API, and JSON over HTTP. The instrumentation you do for OpenObserve works against any OTel-compatible backend.

Fragmented product SKUs

Datadog is sold as a bundle of distinct products (Infrastructure, APM, Logs, RUM, Synthetics, CSPM, Watchdog), each priced separately, each with its own data model and quirks. In OpenObserve, logs/metrics/traces are stream types in one unified store with one UI and one query engine.

Data ownership

In Datadog, raw telemetry lives on Datadog's cluster. You can query it through their UI and API but can't cheaply backfill, re-process, or join it against the rest of your data.

In OpenObserve, raw events live as Apache Parquet in your bucket: S3, GCS, Azure Blob, MinIO, or local disk. Any tool that reads Parquet can read your telemetry data.

Feature Comparison

FeatureDatadogOpenObserve
LogsYesYes
MetricsYesYes
TracesYesYes
Open sourceNoYes
DashboardsYesYes
AlertsYesYes
PipelinesYesYes
OpenTelemetry nativePartialFull
Per-host pricing$15 to $27 / host / month$0
Custom metricsPer-metric overage above quotaUnlimited, included
Self-hosted optionNoYes
Bring your own storageNoYes (S3, GCS, Azure Blob, MinIO)
IAM & SSOEnterprise tier onlyIncluded (SAML, OIDC, LDAP, role-based access)

Architectural Differences

LayerDatadogOpenObserve
Ingest agentsDatadog Agent (proprietary)OpenTelemetry Collector, OTel SDKs, Fluent Bit, Vector
Custom metric protocolDogStatsD (proprietary dialect)OTLP, Prometheus Remote Write, OTel statsd receiver
APM trace protocolDatadog APM intake (dd-trace-*)OTLP (with OTel Collector datadog receiver as a translation layer for existing dd-trace SDKs)
StorageDatadog-managed (opaque)Apache Parquet on object storage
QueryDatadog query DSL + log search syntaxSQL + PromQL
VisualizationDatadog UIOpenObserve UI (built-in)
DeploymentSaaS onlySelf-host or OpenObserve Cloud

Cost Profile

Datadog cost is dominated by per-host + per-product + per-custom-metric line items, with ingest-based add-ons for logs. Adding hosts or custom dimensions to a metric increases cost without any change in data volume.

OpenObserve cost is dominated by ingest + object storage + query compute. There are no per-host, per-user, or per-metric fees. The architecture is designed so that:

  • Long retention is cheap (object storage rates)
  • High host counts don't multiply cost
  • High-cardinality custom metrics don't multiply cost

What Stays the Same

Migrating off Datadog typically does not require re-instrumenting your applications:

  • DogStatsD clients keep sending UDP to port 8125. The OTel Collector's statsd receiver listens on the same port and translates to OTLP.
  • dd-trace-* APM SDKs keep sending spans on port 8126. The OTel Collector's datadog receiver translates the payloads into OTLP traces.
  • Datadog Agent can stay during the migration window. Repoint its dd_url at the local OTel Collector and it continues collecting host and integration metrics without any other change.
  • Log shippers (Fluent Bit, Vector) only need a one-line output swap.

The OpenTelemetry Collector with the appropriate receivers acts as a Datadog-to-OTLP translation layer, so the application surface area stays untouched.

Migration Shape

A typical move off Datadog runs in three steps:

  1. Stand up an OTel Collector alongside the existing Datadog Agent fleet. Configure it with the statsd, datadog, and (optionally) log receivers so it accepts the same wire formats Datadog uses.
  2. Run dual-write. Point apps (or the Datadog Agent itself) at both Datadog and the Collector for a validation window. Compare metrics, traces, and logs side by side.
  3. Cut over. Migrate dashboards and monitors to OpenObserve (the AI Assistant translates Datadog query DSL to PromQL/SQL), then decommission the Datadog Agent.

Teams already on OpenTelemetry can start ingesting into OpenObserve within hours. A full Datadog Agent-based fleet usually completes the move in days to a few weeks.

For the detailed, step-by-step procedure, see the Datadog to OpenObserve Migration Guide:

Need Help?

Was this page helpful?

Last updated on

On this page