Datadog vs Prometheus and Grafana: when each fits
If you face a renewal, a per-host or per-GB bill that keeps growing, or a data location rule that Datadog's hosted regional sites cannot meet, a self-hosted Prometheus and Grafana stack fits best when your team can operate it. Datadog fits best when you want one vendor to run the backend, the agents, and the integrations, and when data location is not a constraint. The choice turns on four questions: where telemetry may reside, how many teams need traces, logs and metrics in one place, and how much in-house operations capacity you have. Prometheus and Grafana cover metrics and dashboards well, while traces and logs need additional components such as Jaeger and Loki, so the stack is a set of projects rather than one product. Data location is the first filter. Datadog runs in separate regional sites, and its documentation states that each site is completely independent and data cannot be shared across sites, so a residency rule must be matched against the specific site you would use. Prometheus stores data in a local time series database that is not clustered or replicated, so durability, retention and recovery become your responsibility. Confirm with your security and compliance leads which telemetry contains personal data, which systems must stay inside a named network, and whether sites such as US1-FED or EU1 meet those obligations in writing before you compare costs. Next, check how many teams need correlated traces, logs and metrics, and whether they operate their own services. A single platform team with a few clusters often runs Prometheus, Grafana, Loki and Jaeger without difficulty, but many product teams that expect APM service maps, log correlation and out-of-the-box integrations usually get more value from Datadog or from an OpenTelemetry-native platform such as SigNoz. Ask who will maintain alert rules, dashboards, retention settings and upgrades, and whether that work fits your existing staff. If no partner is engaged, the stack needs named owners for on-call and patching from day one.
Which option fits which scenario
This table maps common situations to the option that usually fits better, Datadog or a self-hosted Prometheus and Grafana stack. Read each row by its condition: the condition is what should drive the decision, not the tool's brand. The main takeaway is that the open-source stack suits teams with platform capacity and a need for control, while a hosted product suits teams that want one vendor to operate telemetry end to end.
| Scenario | Better fit | Condition that drives it |
|---|---|---|
| Fixed infrastructure metrics with a platform team | Prometheus and Grafana | A defined set of hosts, clusters and services, and engineers who will own scrape configs, retention and upgrades |
| Traces and logs in one hosted product, no operations staff | Datadog | No one on staff will run Prometheus, Grafana, Loki and Jaeger, and the team wants a single vendor for support |
| Strict data residency or air-gapped networks | Prometheus and Grafana | Datadog runs only in its regional hosted sites, so telemetry must stay inside your own network or data center |
| Heavy use of Datadog-specific integrations | Datadog, unless integrations are rebuilt | Many dashboards and monitors depend on Datadog integrations that need Prometheus exporters or new alert rules |
| Team standardized on OpenTelemetry and Kubernetes | Prometheus and Grafana, with OpenTelemetry Collector | Applications already emit OTLP, so the same telemetry can feed either backend during a trial or cutover |
| Need for long-term metric history at scale | Prometheus with remote write to long-term storage | Retention goals exceed local Prometheus storage, which is not clustered or replicated; plan an external store |
| Metrics where every sample must be exact, such as per-request billing | Datadog or another exact-counting backend | Prometheus documents that it favors reliability over precision and is not suited to 100% accuracy requirements |
| Team needs vendor-backed SLAs for the monitoring tool itself | Datadog, or a paid support contract for the open-source stack | Confirm support terms in writing with each vendor, since open-source projects do not provide a support SLA by default |
What the open-source stack is made of
A self-hosted replacement for Datadog's metrics, traces and alerting is assembled from separate projects, each with its own license, release cycle and operating burden. The cards below show what each part does, what it costs to run, and where the license terms and gaps need checking before you commit.
OpenTelemetry for collection
OpenTelemetry is the instrumentation and collection layer, not a backend. Applications emit traces, metrics and logs through OTLP, and the OpenTelemetry Collector routes them to one or more destinations. This is where a Datadog migration starts, because the same telemetry can be sent to Datadog and to your own stack in parallel. Check which Datadog Agent features, such as certain integrations and host metadata, you will need to rebuild as Collector receivers and processors.
Prometheus for metrics and PromQL
Prometheus is an Apache-2.0 metrics system that scrapes targets over HTTP and stores samples in a local time series database. It is queried with PromQL, which replaces Datadog's metric queries and monitors. Its local storage is a single node that is not clustered or replicated, so high availability and long retention need planning. The project itself has no paid enterprise edition, so your costs come from infrastructure, storage and the people who operate it.
Alertmanager for alert routing
Alertmanager receives alerts from Prometheus and handles grouping, inhibition, silences and routing to receivers. It replaces the notification side of Datadog monitors, but not the on-call scheduling and escalation that teams often pay for separately. For high availability, Prometheus should point at every Alertmanager instance rather than a load balancer. Confirm that your receivers, such as chat, email or paging tools, are supported and that duplicate notifications are tested during cutover.
Grafana for dashboards
Grafana provides dashboards and visual exploration over Prometheus, Loki, Jaeger and other data sources. Its core is licensed AGPL-3.0-only, a change made in 2021 from Apache-2.0, so review how the AGPL applies to your modifications and distribution. Production use needs MySQL or PostgreSQL for configuration, not SQLite. Dashboards can be provisioned from files or managed as code, which matters when you rebuild a Datadog dashboard estate. Some authentication features such as SAML are only in Grafana Enterprise.
Jaeger for distributed traces
Jaeger is an Apache-2.0 tracing backend and a graduated CNCF project, and Jaeger v2 is built on OpenTelemetry Collector components. It covers the trace storage and search role that Datadog APM fills, but service maps, latency views and trace-to-log correlation are assembled from several tools and need configuration. Confirm the storage backend you will run for traces, since trace volume drives storage and query cost more than metric volume does.
Loki or Mimir for logs and history
Prometheus local storage is not built for long retention, so teams add Grafana Mimir for horizontally scalable long-term metrics and Loki for logs. Mimir is AGPL-3.0-only, like Grafana. Logs and long-term metrics usually carry most of the storage and operating cost in this stack, so size retention and object storage before you move data. Datadog's Agent is open source, but its backend and UI are not, so the replacement is a rebuild of the backend, not a fork of the Agent.
Datadog vs Prometheus and Grafana feature by feature
This table compares Datadog with a self-hosted Prometheus and Grafana stack across metrics, traces, logs, alerting, storage, access control and configuration. Read each row as the work you would take on: where a capability ships in one product, where it needs a separate component, and where you must confirm details in your own environment. The main takeaway is that the open-source stack covers metrics and dashboards well out of the box, while traces, logs, long-term storage and enterprise access controls each add components or licensing decisions.
| Capability | Datadog | Prometheus and Grafana (self-hosted) |
|---|---|---|
| Metrics collection | Hosted agent with a broad integration catalog and automatic host metrics | Pull-based scraping over HTTP with service discovery; Prometheus also accepts OTLP metrics when the receiver is enabled |
| Traces (APM) | Included APM module with service maps and latency views | Not in Prometheus or Grafana alone; add Jaeger or another OpenTelemetry-compatible tracing backend |
| Logs | Hosted log management billed per GB or event | Not in Prometheus; Grafana Loki is a separate component for log storage and queries |
| Integration catalog | Broad, vendor-maintained catalog of integrations and prebuilt dashboards | Narrower out of the box; confirm exporters and dashboards exist for each technology you run |
| Alerting | Monitors and notifications managed in the platform | Prometheus rules plus Alertmanager for grouping, inhibition, silences and routing; Alertmanager runs as a separate service |
| Local retention and scaling | Retention set by the subscription; scaling handled by the vendor | Default 15-day local retention on a single node, not clustered or replicated; plan sizing and backups yourself |
| Long-term storage | Included in the hosted service, with retention terms set by the subscription | Requires a remote-write system such as Grafana Mimir or another long-term store, operated as its own service |
| Dashboards | Hosted dashboard builder and dashboard APIs | Grafana dashboards, provisioned from YAML or JSON files and deployable as code |
| SSO and SAML | Vendor-managed SSO options under the subscription | LDAP, OAuth, Entra ID, Okta and Google work in all editions; SAML, team sync and SCIM need Grafana Enterprise |
Where traces and logs need extra work on the open-source side
Prometheus covers metrics only. A Datadog-style view that joins a slow request to its trace and its log lines has to be assembled from separate components: Jaeger for traces and Loki or another log store for logs, with Grafana as the shared query and dashboard layer. Prometheus will not store spans or log lines, so the team owns three storage systems, three retention settings and three upgrade paths from the start. Jaeger v2 is built on OpenTelemetry Collector components, which makes it a natural trace backend for an OpenTelemetry pipeline, but the team still has to confirm the trace storage backend and sizing for its own volume.
Correlation is not automatic. It depends on how the team labels telemetry and how it configures Grafana data sources. Services should emit the same service name, environment and version attributes across metrics, traces and logs, and the trace ID should appear in log records so Grafana can link from a log line to a trace. Metrics with exemplars, and the data source settings that connect Prometheus, Jaeger and Loki to each other, must be set and tested per environment. In a proof of concept, a reader should pick one failing request, start from a latency panel, follow an exemplar or label to the trace, and then jump from that trace span to the matching log lines. If any step breaks, the cause is usually a missing attribute or a data source setting, not the tool.
Test the volume as well as the links. Run the expected peak of spans and log lines through the pipeline for a realistic window, then measure how long a log search over a recent time range takes, how much storage one day of traces and logs consumes, and whether the trace backend keeps up with ingestion. Ask the vendor or community maintainers for the sizing guidance for each component, and confirm what retention each store applies by default. Record the results alongside the Datadog bill for the same workload, so the decision rests on measured behavior in your own environment rather than on feature lists.
Where the data lives and who controls it
Datadog holds telemetry in the regional site you select, while a self-hosted Prometheus and Grafana stack runs wherever your team deploys it. The cards cover where data is held, who controls the boundary, how sign-in works and who evidences the controls. Review them before you choose a site, an identity model or a hosting location.
Datadog runs in fixed regional sites
Datadog is a hosted service split into regional sites, including US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED and US2-FED. Datadog's documentation states that each site is completely independent and data cannot be shared across sites. Confirm with Datadog how a site is assigned to your account, whether it can change later, and whether any feature moves telemetry between sites. Your residency answer depends on that site choice.
Prometheus and Grafana run where you place them
With a self-hosted stack, the location of every component is your decision: a cloud account you control, a private data center or a disconnected network. Prometheus local storage is a single node that is not clustered or replicated, so you must plan backups, disk capacity and a remote write target for long-term data. Grafana needs MySQL or PostgreSQL for production and high availability. You set the data boundary, and that boundary includes every backup copy.
Grafana identity in every edition
All Grafana editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. If your directory depends on SAML or SCIM for joiner and leaver automation, that requirement decides whether the open-source edition meets it or whether you need Enterprise. Confirm the protocol list against your identity provider before you design the migration.
Compliance evidence and who issues it
Assessments depend on controls you can demonstrate: access reviews, change records, retention settings and encryption choices. DeployOpen prepares those systems, controls and evidence for a compliance assessment. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Ask which framework applies, which controls the self-hosted stack must evidence, and who owns the log of configuration changes.
What each option costs to own
Datadog bills recurring usage. Host-based charges apply to monitored infrastructure, APM is priced on the tracing component you enable, and log management is billed per GB or per event depending on the plan. These charges follow your fleet size and telemetry volume, so the bill usually rises as services multiply, containers churn and log verbosity grows. The Datadog Agent source is open, but the backend that bills you is not, so your exit cost also includes rebuilding dashboards and monitors.
- Per-host charges: recur for each monitored host. Ask how short-lived hosts, autoscaled nodes and containers are counted.
- APM charges: depend on the services and trace volume you instrument. Ask which span volumes the contract covers.
- Log charges: may bill ingestion, indexing and retention separately. Ask which of these are included.
- Custom metrics and add-ons: high-cardinality series and optional products can add charges. Ask for the rate for each.
- Commitments and overage: ask for the committed amount, the overage rate and whether pricing changes at renewal.
Before renewal, request the price model in writing for each billable dimension, along with a usage report for the last full billing period.
Prometheus, Grafana and Jaeger carry no license fee for the open-source editions, so the cost moves to the infrastructure and people that run them. Each component scales differently, and the largest cost often comes from the part you sized least carefully. Grafana's installation guidance is a reasonable starting point for Grafana install options, but sizing depends on your own query and data volumes.
- Compute: Prometheus is a single-node store, so growth means larger nodes, sharding or a long-term store such as Grafana Mimir (AGPL-3.0-only). Grafana's documented small deployment is under 25 concurrent users at 2 cores and 2 to 4 GB of RAM, and larger teams need more.
- Storage and retention: Prometheus keeps 15 days of local data by default. Longer retention moves cost to disk or object storage and adds remote write infrastructure.
- Grafana database: SQLite is the default, but production and high availability require MySQL 8.0 or later or PostgreSQL 12 or later. You must provision, back up and patch that database.
- Staff and on-call: upgrades, patching, alert tuning and on-call rotation usually account for the largest recurring share. Grafana minor releases arrive every other month, and Prometheus minor releases every 6 weeks.
- Implementation and support: exporters, dashboards and alerts are built once, and optional support or a retainer adds a recurring fee.
Ask any implementation partner to price each component separately, with a named owner and the recurring effort for each.
A fair comparison separates work you do once from costs that repeat every month. For Datadog, most costs recur and the one-time items are migration and exit. For the open-source stack, the build is substantial and then recurring infrastructure and people carry the ongoing cost. Teams often underestimate the overlap period, when both platforms run and both bills apply.
- One-time build: OpenTelemetry instrumentation, exporter configuration, dashboard and alert rebuilds, and hardening of Grafana. Provisioning files and Terraform reduce later rework, but they take time to write.
- One-time migration and dual running: sending telemetry to Datadog and the new stack in parallel during cutover. Ask how long the overlap will last and who pays for each platform during it.
- Recurring infrastructure: compute, disk or object storage, the Grafana database, load balancers and backups.
- Recurring people and support: upgrades, on-call, alert maintenance and any support subscription. Grafana's authentication docs place SAML, team sync and SCIM in Grafana Enterprise and Grafana Cloud only, so identity requirements may add a license cost.
- Cost drivers: metric cardinality, retention period, log volume and team change rate push both sides up, while tighter sampling and retention limits push them down.
Build one table with one-time and recurring columns for each option over the same period, then ask both sides to validate the assumptions behind it.
What a move from Datadog involves
The sequence below moves Datadog metrics, traces, logs, dashboards and alerts to a self-hosted Prometheus and Grafana stack in an order that keeps monitoring running throughout. Each step ends with a check you can confirm before the next one starts.
Inventory hosts, integrations, dashboards and monitors
Your team lists every host running the Datadog Agent, every enabled integration, every dashboard and every monitor, and records which ones are used for paging. DeployOpen can help draft this inventory when the scope is agreed in writing, but your engineers own the list because they know which dashboards are still read. Datadog dashboard definitions can be exported as JSON through its API, so keep those files as a reference for rebuilds. Metrics and traces have no bulk export, so plan to recreate those series from instrumentation. The step is done when each item has an owner and a keep, change or retire decision.
Instrument services with OpenTelemetry
Application teams replace Datadog tracing libraries with OpenTelemetry SDKs or auto-instrumentation, and export through an OpenTelemetry Collector using OTLP. Because Datadog accepts OTLP directly and through its Collector pipeline, the same telemetry can still reach Datadog during the transition. Confirm each language and framework in your estate against the OpenTelemetry documentation, since coverage differs by runtime. The step is done when a sample of services emits traces, metrics and logs through the Collector with the expected service and resource attributes.
Deploy Prometheus, Alertmanager, Grafana and Jaeger
Platform engineers install Prometheus with its storage and retention settings sized for your metric volume, Alertmanager in a cluster for high availability, Grafana with MySQL or PostgreSQL as its configuration database, and Jaeger for traces. Prometheus local storage is not clustered or replicated, so decide early whether long-term storage will use remote write to an external system. Grafana production and high availability setups require MySQL or PostgreSQL rather than SQLite. The step is done when every component is reachable in your environment, backups are scheduled and a test alert reaches its receiver.
Dual-ship telemetry during cutover
Send the same telemetry to Datadog and to the new stack in parallel for a period you agree with stakeholders. This lets teams compare series, dashboards and alert behavior side by side before anyone relies on the new system. Be aware that dual-running adds ingest cost on the Datadog side and infrastructure cost on the open-source side, so confirm both in your own accounting. The step is done when key services show matching metrics and traces in both systems and discrepancies are logged and explained.
Rebuild dashboards and translate monitors to alert rules
Engineers rebuild each kept dashboard in Grafana, using the exported JSON as a reference, and rewrite each Datadog monitor as a Prometheus alert rule routed through Alertmanager. Datadog query language and PromQL differ, so review thresholds, evaluation windows and notification targets individually rather than copying them. Grafana provisioning can store data sources, dashboards and alerting resources as YAML or JSON files, which keeps the rebuilt estate in version control. The step is done when each retired monitor has a replacement rule, a tested notification path and a named owner.
Retire the Datadog Agent and decommission
After stakeholders sign off on the rebuilt dashboards and alerts, remove the Datadog Agent from hosts, disable the integrations and stop exports to Datadog. Confirm your contract terms and data retention obligations with Datadog before cancelling, and keep any archived exports you need for audit or incident history. Revoke API keys and application keys no longer in use. The step is done when no host sends data to Datadog, the old keys are revoked and the decommission record is filed with your compliance team.
Datadog vs Prometheus and Grafana: cost and effort questions
What does it cost to run Prometheus and Grafana compared with Datadog?
The cost of a self-hosted Prometheus and Grafana stack is the sum of infrastructure, storage, implementation and the people who operate it, and no figures are given here. Prometheus and Grafana carry no license fee for the open-source editions, so the recurring cost sits in compute for Prometheus servers and Grafana, object storage for long-term metrics, network egress, backup, and engineer time for upgrades and on-call. Datadog bills by host, by APM usage and by ingested log volume or events, so its cost rises with fleet size and telemetry volume. To compare fairly, ask any quote for each component separately: one-time implementation work, recurring infrastructure, recurring staff time, and any support subscription, then model the volume growth you expect over the contract period.
How long does a migration from Datadog to Prometheus and Grafana take?
The duration depends on the scope of what moves, and no timeline is given here. The main drivers are the number of dashboards and monitors to rebuild, how many integrations need a replacement exporter or Collector pipeline, whether application traces and logs move in the same wave, and how long the team runs both systems in parallel during cutover. Work that is mostly infrastructure metrics is faster than work that also touches custom metrics and alert routing. Ask for a written scope with deliverables and a timeline agreed before work starts, and check that the plan includes a dual-running period and a rollback path for each alert.
Can an internal team run Prometheus and Grafana without outside help?
A capable internal team can run the stack alone, but it needs skills across several areas. Engineers should be comfortable with PromQL, service discovery, Kubernetes or the target platform, OpenTelemetry Collector configuration, Alertmanager routing, Grafana provisioning and database operations for Grafana's configuration store. Security skills matter too, since Grafana's hardening guidance covers cookies, a Content Security Policy and authentication on the metrics endpoint. Assess your team against these areas honestly. Many organizations use a mix of internal ownership and a fixed-scope implementation partner for the initial build, then keep a support arrangement for upgrades and testing.
What does Grafana Cloud pricing show as a reference point?
Grafana's published pricing gives a useful reference for hosted costs, though it does not replace a quote for self-hosting. According to Grafana's pricing page, Grafana Cloud has a free tier, a Pro tier that starts with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. The Pro figure is a platform fee before usage charges, so the total depends on metrics, logs and traces volume. Use these tiers to decide whether a hosted option or self-hosting fits your residency and control requirements, and compare them against the component costs of your own stack.
Is Prometheus accurate enough for billing-grade data?
No, the Prometheus documentation says it is not a good choice where 100% accuracy is required, such as per-request billing. The project states that it values reliability over precision. Prometheus collects samples by scraping targets at intervals, so short-lived work or gaps can be missed, and its local storage is not clustered or replicated. For usage-based charges, keep an authoritative record in a system designed for that purpose, and use Prometheus for operational monitoring and alerting. Confirm the accuracy requirements for each metric with your finance and compliance owners before you design the stack.
How do you set up Grafana for high availability?
Grafana high availability uses two or more active-active Grafana servers behind a load balancer, and all of them share a MySQL or PostgreSQL database. The documentation notes that SQLite does not scale for production, so a supported database is required for high availability. Database-backed auth tokens let users reach any node. Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limitations in an HA setup, so test those behaviors with your own workloads. Plan the database itself for backup and failover, because it becomes the single point the cluster depends on.
Which parts of the stack need the most ongoing effort after launch?
Ongoing effort concentrates in upgrades, storage management and alert hygiene. Prometheus minor releases follow a six-week cycle, and a minor release generally stops receiving bug fixes after six weeks, so plan to move to a supported line, either a current minor or the long-term support line. Grafana publishes major releases once a year, minor releases every other month and patch releases at least monthly, with each minor release supported for 9 months. Local Prometheus storage defaults to 15 days of retention and needs a remote storage system for longer history. Budget staff time for these recurring tasks, and ask any support provider to name its response process for security patches.
How DeployOpen helps you decide and move
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Datadog vs Prometheus and Grafana, we start with a written scope that matches your metrics, traces, logs and alerting needs to the open-source components that will carry them.
How we scope
- Inventory the Datadog hosts, integrations, dashboards, monitors and APM services that the new stack must cover.
- Decide where Prometheus, Grafana, Alertmanager, Jaeger or Loki fit, and where a gap needs a separate tool or manual work.
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy Prometheus, Grafana and supporting components in your cloud accounts, data centers or air-gapped network.
- Plan storage and retention for Prometheus local storage, with remote write to long-term storage where your retention needs require it.
- Configure Grafana authentication, provisioning and security hardening, then test alert routing through Alertmanager before cutover.
How we hand over
- Document the architecture, configuration, dashboards, alert rules and runbooks so your own team can operate the stack.
- Provide the controls and evidence that support your compliance assessments, while independent auditors issue any reports or certifications.
- Run a parallel-run period with OpenTelemetry dual shipping so your team can compare Datadog and open-source results side by side.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, matched to your release cadence.
- Patch and upgrade Grafana and Prometheus on the vendor and project schedules, including long-term support lines where you choose them.
- Confirm the team, retainer scope and ownership split for operations with you in a written quote based on the agreed scope.
