Does self-hosted Prometheus and Grafana cost less than Datadog?
Prometheus, Grafana and Loki carry no license fee for the software itself, so the cost comparison turns on infrastructure, storage, staff time and migration rather than on the code. Prometheus is licensed under Apache-2.0 and has no paid enterprise edition, so its costs are the servers, disks and people who run it. Grafana was relicensed from Apache-2.0 to AGPL-3.0-only on April 20, 2021, and Loki moved to AGPLv3 on the same date. AGPL obligations matter if you modify and offer these tools to users over a network, so have legal review them, but they do not add a per-host or per-GB charge. Datadog's prices are not supplied for this comparison, so use your own invoices and renewal quote as the baseline for every line in the model.
Build the model by component. On the Datadog side, separate per-host infrastructure charges, APM charges, and log charges per GB or event, and identify which ones grow with usage and which are fixed by contract. On the self-hosted side, list compute for Prometheus, Grafana and Loki, object storage for Loki chunks and indexes (Loki's recommended production stores include Amazon S3, Google Cloud Storage and Azure Blob Storage), block storage for Prometheus's local database, which defaults to 15 days of retention, and the Grafana database, which must be MySQL or PostgreSQL for production. Add the staff time to operate, upgrade and secure these systems, plus the one-time migration and the months of dual running while OpenTelemetry sends the same telemetry to both platforms.
Grafana Cloud is a different path from self-hosting. Its pricing page lists a free tier, a Pro tier with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a 25,000 US dollar annual minimum, so it has its own usage-based bill. Ask any vendor, including Grafana Labs, for a written quote that shows the usage assumptions behind it. For self-hosting, ask your implementation partner for a written scope covering sizing, high availability, backup, upgrades and support, since those are the costs that most often differ from the software-only view. Run the model against several retention and growth scenarios before the renewal date, and label any scenario you build as illustrative.
Which cost components move when you replace Datadog
This table compares each Datadog cost line with the matching self-hosted cost for Prometheus, Grafana and Loki, and marks whether it is one-time or recurring. Read it as a checklist for building a like-for-like estimate, since most self-hosted costs are staff and infrastructure rather than license fees. The main takeaway is that the open-source software itself carries no license charge, so the total depends on storage configuration, retention and the people who run the stack.
| Cost component | Datadog (commercial side) | Self-hosted stack (open-source side) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Per-host infrastructure charges, plus APM and per-GB or per-event log charges, billed as a subscription | No license fee for Prometheus (Apache-2.0) or Loki (AGPLv3); Grafana is AGPLv3 and Grafana Enterprise is a separate paid option | Recurring for Datadog; none for the core open-source software |
| Compute for Prometheus, Grafana and Loki | Not applicable; Datadog runs the backend in its regional sites | Virtual machines or Kubernetes capacity for each component, sized by series count, query load and log volume | Recurring |
| Object storage and retention | Log retention is a billed tier; Datadog charges by ingested and indexed volume | Loki stores chunks and index in object storage; retention is disabled by default, so storage grows until you configure it | Recurring, driven by retention settings |
| Local metric storage | Included in the subscription, with retention set by the plan | Prometheus keeps 15 days by default in local storage; longer retention needs remote write to external storage | Recurring |
| Implementation | Agent rollout and tagging through Datadog's own tooling | Installing and configuring the stack, exporters, OpenTelemetry Collector pipelines, alert rules and dashboards | One-time |
| Migration and dual running | Little or none for the current subscription | Running Datadog and the new stack in parallel while telemetry is dual-shipped via OTLP, plus translating monitors and dashboards | One-time, with a parallel recurring period during cutover |
| Support | Included with the subscription at the vendor level | Community support, or a paid subscription or retainer from a vendor or implementation partner; confirm terms in writing | Recurring if you buy support |
| Upgrades and internal skills | Vendor handles backend upgrades | Your team or partner applies patches, plans Grafana and Loki upgrades, and staffs on-call for the stack | Recurring |
What moves the Datadog comparison most
The cost of a self-hosted Prometheus and Grafana stack shifts with the same inputs that drive Datadog's bill, but each input lands on a different line: infrastructure, storage, and people. The cards below show which driver changes which component, so you can build a quote and a total cost model from your own telemetry profile rather than from averages.
Host count and scrape volume
Datadog bills per host, so every added node or container host raises the subscription directly. In Prometheus, the same growth raises active series, memory use on the Prometheus server, and disk for the local time series database. Measure your active series count and scrape interval before modeling, because the number of metrics per target often matters more than the number of targets. Ask your team to confirm how Datadog counts hosts in your contract, since that definition sets the baseline.
Log volume and retention period
Datadog charges per GB or per event for logs, and retention length usually adds to that charge. In Loki, the cost moves to object storage, compactor capacity and query compute. Retention is disabled by default in Loki, so logs are kept indefinitely until you set retention_enabled, which means someone must own that setting. Model storage by retention window and compressed volume per day, not by ingest alone.
Trace volume and sampling
Datadog APM charges by host or by indexed spans, depending on your contract, so trace volume and sampling policy drive the APM line. Self-hosted tracing with Jaeger or SigNoz moves that cost to storage and to the cluster that receives spans. Decide sampling rules early, because they set how much storage you pay for and how much detail you can investigate. Confirm which Datadog APM and ingestion components apply to your account before comparing.
Number of users and dashboards
Grafana's free self-managed editions do not charge per user, but single-user access controls differ by edition. Under the Grafana authentication docs, SAML, team sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, so a team that needs them must budget for the enterprise license or build its own provisioning. Dashboard count affects query load on Prometheus and Loki more than license cost, so plan query capacity alongside seat counts.
Availability requirements
Grafana high availability uses two or more active-active servers behind a load balancer, sharing a MySQL or PostgreSQL database, while Prometheus local storage is not clustered or replicated. Each redundant node, database and load balancer adds compute and operating cost that a single Datadog subscription hides. The Grafana docs also note that alerting needs extra configuration to avoid duplicate notifications. Ask what uptime your alerting must meet, because that answer sets the number of components.
Team skills and on-call ownership
The largest recurring cost in a self-hosted stack is often the staff time to upgrade, patch, tune and respond to incidents on the stack itself. Grafana's upgrade guidance includes minor releases every other month and patch releases at least monthly, and each minor release is supported for 9 months, so someone must run that cycle. Identify who owns Prometheus, Grafana and Loki before quoting, and ask a partner to price that ownership separately from infrastructure.
How to build the comparison with your own numbers
This sequence turns your current Datadog invoices into a like-for-like model of self-hosted Prometheus, Grafana and Loki costs, so the comparison rests on your telemetry volumes and staffing rather than on generic estimates. It ends with two totals measured over the same horizon, including the one-time and dual-running costs that are easy to leave out.
Export Datadog invoices by product line
Finance or the account owner pulls the last twelve months of Datadog invoices and usage reports, separated by product line: infrastructure hosts, custom metrics, APM, log ingestion and indexing, log retention, and any synthetic or RUM charges. Keep the line items as billed, including overage and committed-use terms, because the contract sets the baseline you are comparing against. Done when every recurring charge maps to one product line and the total matches the invoices for the period.
Measure hosts, series, log volume and traces
The platform team reads the usage data for the same period and records the volumes that drive each charge: billable hosts by size, custom metric series per month, log gigabytes ingested and indexed, retention days per log index, and trace or span volume per day. Note peak values as well as averages, since some billing models bill on the high-water mark. Done when each volume has a number, a unit and a source report that a second engineer can reproduce.
Size Prometheus retention and remote storage
The platform team sizes Prometheus local storage from the series count and scrape interval, then compares it with the default local retention of 15 days. If you need longer history, they size a remote write target, since local storage is not clustered or replicated and is managed like a single-node database. Illustrative example: 500,000 active series scraped every 30 seconds will need local disk in proportion to series count and retention, so doubling retention roughly doubles disk. Done when the disk, memory and remote storage figures are written down with the retention period they assume.
Size Loki object storage from log volume
Using the daily log gigabytes and the retention period from step two, the team calculates compressed object storage, adding headroom for the index and for ingest bursts. Loki applies retention only when the compactor is configured for it, and logs are kept indefinitely otherwise, so confirm that setting in the plan. Also confirm which object store you will use, since the Loki docs recommend Amazon S3, Google Cloud Storage or Azure Blob Storage for production. Done when the storage size, the object store price list you will use, and the retention setting are recorded together.
Estimate monthly staff time to run the stack
The engineering manager estimates the hours each month spent on upgrades, patching, Grafana high availability with a shared MySQL or PostgreSQL database, alert routing, on-call for the monitoring stack itself, backups and capacity reviews. Separate time already spent on Datadog today, such as dashboard upkeep and monitor tuning, so you do not double count it. Ask whether internal salaries, an implementation partner's retainer, or both will cover this work. Done when the hours are listed by task and converted to a monthly cost at an agreed loaded rate.
Add one-time migration and dual-running costs
The team lists one-time costs: instrumentation changes, exporter and Collector setup, dashboard and monitor rebuilds, testing, and any implementation fees agreed in a written scope. Then it adds the dual-running period, when Datadog and the new stack both receive telemetry, which means paying for both platforms and for the extra infrastructure during cutover. Ask vendors and partners to state which costs are fixed and which scale with volume. Done when each one-time item has an owner, an amount or effort estimate and a stated end date for dual running.
Compare totals over one shared horizon
The team builds one table with the same number of months for both options, showing Datadog recurring charges against the self-hosted recurring costs (compute, storage, network, staff time) plus the one-time and dual-running costs in their correct months. Run the table at current volume and at a higher volume to see which inputs move the result most. Done when both totals cover the same horizon, every assumption is labeled, and the open questions are listed for the vendor, the partner and your own finance team.
Why dual running costs more than the cutover date suggests
Dual running keeps Datadog billed for as long as the overlap lasts, so the overlap is a cost line, not a free safety net. Because Datadog, New Relic and Dynatrace all document OTLP ingestion, an OpenTelemetry Collector can fan the same metrics, traces and logs out to Datadog and to a self-hosted Prometheus, Grafana, Loki or Jaeger stack in parallel. That makes validation easy to start, but every day of parallel shipping is a day of host, APM and per-GB or per-event charges on the commercial side, plus the compute and storage of the new side. Ask Datadog for the billing terms that apply to your contract and model the overlap against them before the cutover date is set. Set the overlap length from exit criteria, not from the calendar. Measure parity per service: that every host and service still reports, that metric names and label sets match what the dashboards and alerts expect, that trace sampling produces comparable latency and error views, and that log volume and retention on the Loki side match the volume you expect to pay for. Track alert behavior too, since a Datadog monitor and a Prometheus alert rule can fire on different thresholds or evaluation windows. Set the criteria in writing with the owning teams, and check them against the Prometheus storage default retention of 15 days if you intend to rely on local storage before remote long-term storage is in place.
Dashboards and monitors are rebuilt, not copied, because the query languages and data models differ. Datadog dashboard JSON is useful as a reference for panels, grouping and thresholds, but its queries have to be rewritten in PromQL and LogQL, and each monitor has to be re-expressed as an alert rule with its own grouping and routing through Alertmanager or Grafana alerting. Plan for review time from the people who own each service, because a translated query that returns data is not the same as a query that answers the same operational question. Confirm which Grafana edition and authentication model you need before building shared dashboards, since SAML and team sync are limited to Grafana Enterprise and Grafana Cloud according to the Grafana authentication docs. The Prometheus release cycle is a reason to budget upgrade effort into the run phase, not into the migration itself. Each minor release is supported only for a limited period, and long-term support lines receive fixes for one year, so the team that operates the stack must schedule upgrades and test them against exported dashboards and alert rules. Ask who owns that work after cutover, whether it sits in-house or in a retainer, and whether it is covered in the written scope of any implementation partner. Dual running ends only when that owner exists.
Which self-hosted layout fits which telemetry size
Monolithic mode runs Loki as a single binary that handles reads, writes and compaction together. Loki's deployment documentation places this mode at logs up to about 20 GB per day, which suits a single team or a pilot that replaces part of a Datadog log workload.
- Staff effort: one service to upgrade, monitor and back up, usually owned by one platform engineer alongside other duties.
- Storage: chunks and the index go to object storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage, so the node itself stays small and replaceable.
- Retention: the compactor enforces retention, which is disabled by default, so someone must set it deliberately or logs accumulate indefinitely.
- Access control: Loki has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front of it.
- Scaling limit: when daily volume approaches the documented ceiling, the move to a larger mode is a re-platforming project, not a configuration change.
Before committing, confirm the current sizing guidance and the object store options with Grafana Labs, and measure your actual daily ingest from Datadog billing or the log pipeline.
Simple scalable mode splits Loki into separate read, write and backend targets, which lets each path scale on its own. Grafana's deployment documentation describes this mode as approaching 1 TB per day, but it also states that the mode is being deprecated and will be removed with the Loki 4.0 release, so it is a poor base for a long-lived platform.
- Staff effort: more moving parts than monolithic mode, with separate scaling and failure domains to watch.
- Deprecation risk: teams that adopt it now must plan a move to a supported mode before Loki 4.0 arrives.
- Storage and index: TSDB is the recommended index store for current releases, with object storage holding chunks.
- Cost drivers: compute for read and write targets, object storage capacity and egress, and the engineering time to tune them.
- Skill requirement: someone must understand the read and write paths well enough to diagnose slow queries and ingest backpressure.
Before committing, ask Grafana Labs for the current migration path from simple scalable mode and the target release date for Loki 4.0, and confirm whether your volume is better served by microservices or by a managed Grafana Enterprise Logs option.
Microservices mode breaks Loki into individually scaled components, which is the layout Grafana's deployment documentation reserves for very large clusters. Each component can be sized and restarted separately, but the operational surface area is the largest of the three options, and it fits organizations with a dedicated observability team.
- Staff effort: a dedicated team typically owns capacity planning, Helm or Kubernetes operations, upgrades and on-call for the logging path.
- Recurring cost: compute across many components, object storage growth, and cross-zone network traffic.
- One-time cost: design of tenancy, retention, labeling and ingest pipelines, plus load testing before cutover.
- Multi-tenancy: setting auth_enabled and passing the X-Scope-OrgID header correctly matters more at this scale, and access rules must be enforced at the proxy layer.
- Support: commercial support from Grafana Labs is a separate contract, so price it alongside the staffing plan.
Before committing, request sizing and reference architectures for your daily volume from Grafana Labs, and have your own platform team confirm that the Kubernetes and storage skills exist in-house.
A single Prometheus server scrapes metrics and keeps a local time series database, with a default retention of 15 days. The storage documentation says local storage is not clustered or replicated and should be run like any other single-node database. Remote write lets the server forward samples to long-term storage, which is how many teams extend retention beyond the local window.
- Staff effort: modest for one server, but backup, disk monitoring and upgrades still need an owner, and upgrades must follow the 6-week minor release cycle or move to the LTS line.
- Local retention: the default 15 days can be set by time or size, which controls disk cost on the node.
- Long-term storage: a remote write target such as Grafana Mimir (AGPL-3.0-only) or another compatible system carries history, and that system becomes another component to run.
- Alerting: Alertmanager should run in a cluster for high availability, with Prometheus pointed at every instance rather than a load balancer.
- Limits: Prometheus favors reliability over precision, so per-request billing or exact accounting calls for a different design.
Before committing, confirm the Prometheus LTS line you will run, the remote write target and its license terms, and who is on call for a single node that holds your alerting.
Questions buyers ask before estimating Datadog replacement cost
How much staff effort does self-hosting Prometheus and Grafana actually take?
The effort is mostly recurring operations time, and it depends on how many metrics, dashboards and alert rules you run, how many environments you cover and how much on-call coverage you need. Prometheus has no paid edition, so the license is free, but someone must run each server, upgrade it and watch its storage. Prometheus stores data locally in a single-node time series database with a default retention of 15 days, and its storage docs state that local storage is not clustered or replicated. Long-term storage, high availability and upgrades add work on top of that. Ask any implementation partner to break the estimate into setup, steady-state operations and upgrade cycles so you can compare it with the staff time you spend on Datadog today.
How long does a migration from Datadog take, and what sets the timeline?
The timeline depends on scope and environment, not on a fixed figure. The main drivers are how many Datadog integrations and hosts you monitor, how many dashboards and monitors must be rebuilt, whether applications already emit OpenTelemetry, and how long you run both systems in parallel during cutover. Teams that instrument with OpenTelemetry can send the same telemetry to Datadog and a self-hosted backend while they validate results, which usually lengthens the overlap but lowers the risk. Change approval windows, the number of teams involved and any compliance evidence you must keep also affect the schedule. Ask for a timeline tied to a written scope with named deliverables, not a generic duration.
Can our internal team run the stack without outside help?
Many teams can, provided they already operate Linux servers, containers or Kubernetes and have an owner for alerting. The open-source components are free to use, so the question is whether your staff have time and skills for installation, hardening, backups, upgrades and tuning. Grafana's installation docs list packages for common Linux distributions, Docker images and Helm charts, and small deployments can run on modest hardware, but production use needs MySQL or PostgreSQL rather than the default SQLite. Outside help is most useful for the first build, for the migration of dashboards and alerts, and for a review of the design. Decide early which of these you will own internally after the handover.
What skills does the work need from our team?
Expect to need four skill areas: Kubernetes or virtual machine administration, storage administration, alert design and dashboard ownership. Prometheus is queried with PromQL and scrapes targets found through service discovery or static configuration, so engineers must understand how their services expose metrics. Long-term data usually goes to object storage, and Loki stores its chunks and index there, which means someone must manage buckets, lifecycle and retention. Loki retention is disabled by default and is applied by the compactor, so the team must set it on purpose. Alert tuning is continuous work, because noisy rules create fatigue and missed rules create blind spots. Grafana also needs an authentication decision, since SAML and SCIM are available only in Enterprise and Grafana Cloud, and Loki has no built-in authentication layer.
Does Grafana Cloud sit between Datadog and running everything ourselves?
Yes, Grafana Cloud is a hosted option built on the same open-source projects, so it reduces server operations while keeping open formats and dashboards. Its pricing page lists 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. Usage-based charges depend on the volume of metrics, logs and traces you send, so the bill still scales with telemetry. Grafana Cloud also keeps your data on a vendor-hosted service, which matters for residency or air-gapped requirements. Compare its usage charges with the Datadog bill and with the staff time you would save, then confirm the tier, data location and exit terms in writing.
What should a written quote for this migration include?
A useful quote separates one-time work from recurring costs and names each deliverable. Ask for the scope of hosts, services, dashboards, monitors and log sources, plus the list of integrations that will be rebuilt, not just the agent swap. Look for the design of storage, retention, high availability and backups, the plan for dual running and cutover, and the rollback steps. Recurring items should include who runs upgrades, how long each Grafana minor release is supported (9 months, with 15 months for the last minor of a major version, according to Grafana's upgrade guidance) and what support or retainer covers patching. Also ask which infrastructure costs you pay directly, such as compute and object storage, and what the vendor assumes about them. DeployOpen prepares a fixed-scope written proposal, so ask for its scope, deliverables and timeline before work starts.
Licensing terms that affect the business case
Licensing decides which costs are fixed and which parts of the stack you can change later, so confirm each license with your legal team before you write the business case. Prometheus is licensed under Apache-2.0, and the project has no paid enterprise edition, so the license itself adds no fee. Your costs come from infrastructure, storage, implementation and the people who run it. Grafana, Loki and Mimir are different. On April 20, 2021, Grafana Labs moved Grafana and Loki from Apache License 2.0 to AGPLv3, and Mimir is AGPL-3.0-only. Grafana Enterprise is a separate commercial product with non-AGPL terms, and it is a distinct line item if you choose it.
AGPLv3 places few conditions on internal use. Your staff can run, configure and use Grafana and Loki across the organization without distributing source code. The obligations arise when you distribute modified versions or offer them to third parties over a network, such as a customer-facing portal built on a modified Grafana. Plugins, SDKs and agent software carry their own licenses, so check each component you add, including the collector you use to ship telemetry. If a team plans to embed or resell any of these components, ask counsel to review that use before it goes into the design.
Datadog's backend and UI are not open source, so you cannot inspect, modify or self-host them. The Datadog Agent is different: its user space components are Apache-2.0 and its eBPF code is GPL-2.0, according to the datadog-agent repository. That split matters for migration planning, because you can review the agent code you are replacing but you cannot keep the Datadog backend running on your own hardware. Ask counsel to confirm the terms of your current Datadog contract, including data processing and exit provisions, since those terms, not the open source licenses, govern how you leave.
How DeployOpen scopes a fixed-price cost comparison and migration
DeployOpen starts with a written scope that compares your current Datadog spend by component against a self-hosted Prometheus, Grafana and Loki stack in your own infrastructure. The scope is agreed in writing before work begins, and the quote follows from that scope.
How we scope
- We inventory Datadog hosts, APM usage, log volumes, retention settings and custom metrics from your current invoices and account settings.
- We size compute, object storage, retention and Prometheus and Loki capacity for your telemetry, and state the assumptions behind each figure.
- We set out staff time to run the stack, including on-call and upgrade effort, and list the items your team must confirm before work starts.
How we build
- We stand up a proof of concept of Prometheus, Grafana and Loki in your cloud account, data center or air-gapped network.
- We run OpenTelemetry Collector pipelines alongside Datadog so you can compare the same telemetry in both systems during cutover.
- We test alert rules, dashboards, authentication and backup restores against agreed acceptance criteria before any traffic moves.
How we hand over
- We deliver the cost model, architecture, configuration as code and runbooks, so your team can rerun the comparison with its own numbers.
- We document the Datadog spend baseline, the dual-running period and the decommissioning steps, so finance and engineering share one record.
- We train your operators on upgrades, retention changes, capacity checks and incident handling for the self-hosted stack.
How we support
- Engagements are fixed-scope, and we agree deliverables and timelines in writing before work starts.
- Ongoing support, upgrades and continuous testing of the stack are available as a retainer after handover.
- We prepare configuration and evidence for your own compliance assessments, while independent auditors issue any audit reports.
