What if the biggest difference between two observability platforms has nothing to do with dashboards, and everything to do with where your data physically lives? That is the question teams keep circling back to when they compare Grafana and Datadog. On the surface, both show charts, fire alerts, and help you find the slow query that ruined a Tuesday afternoon. Underneath, they are built on opposite assumptions about storage, ownership, and control. Understanding those assumptions is what separates a good decision from an expensive one. (Kubernetes architecture control plane worker nodes fit)
Two Platforms, Two Very Different Betting Strategies
Grafana is, at its heart, a visualization and query front end. It does not store your metrics. It connects to data sources — Prometheus, Loki, Tempo, Mimir, SQL databases, Elasticsearch — and renders whatever they return. The platform’s own data source documentation describes this plugin model in detail: Grafana is the glass, and you choose what to pour into it.
Datadog is the opposite. It is a vertically integrated SaaS platform with its own agent, its own intake pipeline, its own storage, and its own query engine. You install the agent, it ships data to Datadog’s cloud, and everything after that happens inside Datadog’s multi-tenant backend. The agent documentation makes clear that there is no self-hosted Datadog. You rent the whole stack.
Neither approach is wrong. But they fail in different ways, and they cost money in different ways. That is the decision you are actually making.
The Storage Question Nobody Asks Until the Bill Arrives
Here is the practical trap. Teams often pick a platform based on the demo — the pretty dashboards, the slick anomaly detection, the prebuilt integrations. Then six months later they discover that cardinality, not volume, drives the bill.
Datadog’s custom metrics documentation explains how custom metrics are counted and billed; read it before you instrument anything. Every unique combination of tag values can become its own time series. Add a user ID tag to a request metric and a single metric can become millions of series overnight. This is not a Datadog flaw; it is how per-metric pricing works everywhere. But it means your tagging strategy is a financial decision as well as a technical one.
Grafana’s answer is different. Because Grafana queries external backends, the cost lives wherever the backend lives. Self-hosted Prometheus on your own hardware has no per-series invoice, but it has an operational invoice: someone has to run it, scale it, and keep it alive at 3 a.m. Grafana’s own backends — Mimir for metrics, Loki for logs, Tempo for traces — can be self-hosted or consumed through Grafana Cloud, which shifts the cost model again.
The mistake people make: comparing list prices without modeling their own cardinality. A team with 50,000 active series and a team with 5 million will get wildly different answers from the same two vendors. Model your actual tag explosion before you sign anything.
Pull Versus Push, and Why It Shapes Your Whole Pipeline
Prometheus, the de facto standard for metrics collection, uses a pull model. It scrapes targets on a schedule and stores what it finds. PromQL, its query language, is the reference design most Grafana deployments build on. Prometheus joined the Cloud Native Computing Foundation in 2016 and graduated in 2018, which matters because it means the ecosystem around it is governed by a neutral foundation rather than a single vendor. (Prometheus: Overview)
Datadog uses a push model. The agent collects locally and ships data outward. That is simpler to reason about in some environments — especially short-lived containers and serverless functions that cannot be scraped — but it also means your data leaves your network by design.
In practice, many mature teams run both patterns. They scrape with Prometheus inside the cluster and push business metrics through an agent. If you are designing that hybrid, it helps to understand how the control plane and worker nodes interact in Kubernetes architecture, because scrape targets and agent DaemonSets live in very different places in that topology.
OpenTelemetry Is the Interoperability Hinge
The single most important architectural shift to understand is OpenTelemetry, the vendor-neutral standard for traces, metrics, and logs. The official OpenTelemetry documentation describes the APIs, SDKs, and collector that let you instrument once and export anywhere.
This changes the Grafana-versus-Datadog conversation fundamentally. If your instrumentation is OpenTelemetry-native, the backend becomes a swappable component rather than a permanent commitment. Grafana’s OTel-native backends accept that data directly. Datadog supports OTLP ingestion too. So the lock-in question shifts from “which vendor do I pick” to “how cleanly can I move if I change my mind.”
The practical tip here: instrument with OpenTelemetry from day one, even if you are not sure which platform you will end up on. Teams that skip this and use proprietary agents often spend months rewriting instrumentation during a migration. Teams that adopt OTel early treat the backend as infrastructure, not identity.
The Self-Hosted Question and Data Sovereignty
For regulated industries — healthcare, finance, public sector — the ability to keep telemetry inside a controlled boundary is not a nice-to-have. It is a compliance requirement.
Grafana wins this conversation by default because it can run entirely inside your own environment. You can deploy Grafana, Mimir, Loki, and Tempo on your own infrastructure and never send a byte to a third party. That is a genuine architectural advantage for teams with data residency constraints.
Datadog has no self-hosted option. If your regulator requires telemetry to stay in-country or on-premises, that settles the decision quickly. For everyone else, it becomes a trade: operational burden versus managed convenience.
The honest framing is that self-hosting is not free. It means owning upgrades, capacity planning, and incident response for your observability stack — which is ironic, because observability is supposed to help you during incidents. Many teams underestimate this. A useful middle path is understanding how platform as a service architecture works in modern PaaS platforms, because the same managed-versus-owned trade-offs apply to your telemetry backend as to your application runtime.
Where the Data Physically Sits Changes Your Failure Modes
Consider what happens when your observability platform goes down during an outage. With a SaaS platform, your monitoring and your incident happen in the same blast radius only if your network path to the vendor fails. Usually the vendor stays up while you are down, which is exactly what you want.
With self-hosted Grafana querying self-hosted Prometheus, your observability stack shares fate with your infrastructure. If the cluster is on fire, the dashboards may be too. Experienced teams solve this by running observability in a separate cluster or account, and by designing for the same resilience they would demand of any critical system. The principles in cloud disaster recovery architecture for systems that must survive failure apply directly here: separate the watcher from the watched.
This is a subtle point that rarely appears in comparison articles, but it is one of the most consequential architecture decisions you will make.
Scaling to Billions of Series Without Losing Your Mind
Both platforms can handle enormous scale, but they get there differently. Datadog scales by adding capacity inside its own multi-tenant backend — you do not think about it, you just pay for it. Grafana scales by scaling whatever backend you chose, which means you own the sharding, replication, and retention decisions.
That ownership is real work. If you are storing high-cardinality data at volume, the design patterns in object storage architecture with flat namespaces at billions scale become relevant, because many modern telemetry backends lean on object storage for long-term retention. Understanding how those systems index and retrieve data helps you set retention policies that do not bankrupt you. (Cloud data warehouse architecture modern analytics engines)
A common practical mistake: keeping raw high-cardinality data forever because “storage is cheap.” It is not cheap when every query scans it. Set retention tiers deliberately — hot for a week, warm for a month, cold for a year — and let the backend do the work.
Cost Modeling That Survives Contact With Reality
| Decision | Grafana Approach | Datadog Approach |
|---|---|---|
| Data storage | Your backends, your cost | Vendor-managed, per-unit pricing |
| Cardinality risk | Bounded by your backend capacity | Directly billed per series |
| Self-hosting | Fully supported | Not available |
| Operational burden | Yours | Vendor’s |
| Migration path | Swap data sources | Re-instrument or re-export |
| Time to first dashboard | Longer setup, flexible | Fast, opinionated |
The table oversimplifies, but it captures the shape of the trade. Grafana asks for engineering time upfront and rewards you with flexibility. Datadog asks for money upfront and rewards you with speed. (Time series database)
The teams that get this right usually run a small pilot: instrument a representative service with OpenTelemetry, send it to both platforms, and compare the actual bill and the actual query experience after 30 days. That beats any spreadsheet.
What Actually Works in Practice
A few patterns show up again and again among teams that are happy with their choice.
First, they standardize on OpenTelemetry before picking a backend. Second, they treat tagging as a schema design problem and review new tags the way they review database migrations. Third, they separate their observability infrastructure from their production workload so a bad deploy does not blind them. Fourth, they accept that the decision is reversible if instrumentation is portable — and expensive if it is not.
The teams that struggle are usually the ones that picked based on a demo, instrumented with proprietary agents, and discovered their cardinality problem only when finance forwarded the invoice.
Conclusion
Grafana and Datadog are not really competitors in the same category. One is a composable front end that assumes you will own your data. The other is an integrated platform that assumes you would rather not. The right answer depends on three things: how much operational ownership your team can absorb, how strict your data residency requirements are, and how portable you have made your instrumentation.
Get the OpenTelemetry layer right, model your cardinality honestly, and separate your monitoring from the systems it watches. Do those three things and the platform choice becomes a manageable trade rather than a permanent trap.
Frequently Asked Questions
Can Grafana store data on its own?
Not in the traditional sense. Grafana is a query and visualization layer that reads from external data sources. Its companion projects — Mimir for metrics, Loki for logs, Tempo for traces — do store data, but they are separate components you deploy or consume through Grafana Cloud.
Is Datadog available as a self-hosted product?
No. Datadog is a SaaS platform. The agent runs on your infrastructure, but all storage and querying happen in Datadog’s cloud. Teams with strict data residency rules should factor this in early.
Which platform is cheaper?
There is no universal answer. Datadog’s per-metric, per-log, and per-span pricing means cost scales with cardinality, while Grafana’s cost depends on the backends you choose. A team with modest telemetry may find Datadog simpler and comparable in price. A team with massive cardinality often finds self-hosted Grafana backends cheaper but more labor-intensive.
What is OpenTelemetry and why does it matter here?
OpenTelemetry is a vendor-neutral standard for instrumenting applications to produce traces, metrics, and logs. It matters because it decouples your instrumentation from your backend, making a future migration far less painful.
Does Grafana work with Prometheus only?
No. Grafana supports dozens of data sources through plugins, including SQL databases, Elasticsearch, and cloud provider monitoring services. Prometheus is simply the most common starting point in Kubernetes environments.
How long does it take to migrate between the two?
That depends almost entirely on instrumentation. If you used OpenTelemetry from the start, migration is mostly a configuration change measured in weeks. If you used a proprietary agent, expect to rewrite instrumentation and rebuild dashboards, which can take months for a large estate.
