When does New Relic cost more than a self-hosted Grafana and Prometheus stack?
New Relic costs more than a self-hosted Grafana and Prometheus stack when your telemetry volume and seat mix grow faster than your ability to absorb the operating work of running the backend yourself. New Relic bills by GB ingested regardless of data type and includes 100 GB ingested per month free, according to New Relic's pricing and billing documentation. Its three billable user types (Basic, Core and Full platform) add a second variable, so the bill scales with both telemetry volume and who holds which seat. If you are facing a renewal, pull the last twelve months of ingest by data type and the current user counts by type before you compare anything.
The self-hosted side replaces those per-unit charges with components you pay for directly: compute and storage for Prometheus, Grafana and any long-term metrics or log store, network egress, upgrades, backups, and the staff time to run them. Prometheus itself carries no license fee, since it is Apache-2.0 and has no paid enterprise edition, so its cost comes from infrastructure and people. Two costs are one-time: the implementation and the rebuild of New Relic dashboards and alert conditions in Grafana. Storage and retention are the recurring line most often underestimated, because Prometheus local storage is single-node and defaults to 15 days of retention, so longer history means a remote storage system with its own cost.
There is no universal winner. A team with modest log volume, a small number of engineers who already run Kubernetes and a strong existing OpenTelemetry footprint can come out well ahead on the self-hosted side. A team with high data volume but few platform engineers may find the staff time outweighs the savings. Before deciding, ask your vendor for a quote that breaks out ingest and user charges by year, and model your own volume against the free tier and each cost component. Confirm with Grafana and Prometheus maintainers which retention and high availability settings your scale requires.
Cost components on each side, and which ones are one-time or recurring
This table sets each New Relic billing component beside the matching cost on a self-hosted Grafana and Prometheus stack, marking whether it is one-time or recurring and who receives the payment. Read the New Relic column for what the subscription covers and the self-hosted column for what your team or a partner must fund and run.
| Cost component | New Relic side | Self-hosted Grafana and Prometheus side |
|---|---|---|
| Data ingest or subscription (recurring) | Billed per GB ingested regardless of data type, with 100 GB per month free; paid to New Relic each billing period | No license fee for Prometheus (Apache-2.0, no paid enterprise edition); Grafana Enterprise is a separate commercial option; storage and compute are paid to your cloud or hardware vendor |
| User licenses (recurring) | Basic, Core and Full platform user types; Core Compute offers consumption pricing with unlimited users based on queries, alerts and API calls | Open-source Grafana has no per-user license; Grafana Enterprise and Grafana Cloud pricing must be confirmed from Grafana's pricing page, which lists a 19 US dollar monthly platform fee for Cloud Pro plus usage and a 25,000 US dollar per year minimum for Enterprise |
| Compute for collection and query (recurring) | Included in the subscription; not billed separately | Prometheus, Loki, Grafana and Alertmanager servers paid to your cloud or hardware provider; sizing depends on series count, log volume and query load |
| Object storage for Loki (recurring) | Not applicable; logs are stored and retained by New Relic under its billing | Loki stores chunks and index in object storage such as S3, Google Cloud Storage or Azure Blob Storage; retention stays disabled until configured, so storage grows until you set it |
| Prometheus local and remote storage (recurring) | Retention is set by New Relic's data policies and billed through ingest | Local TSDB defaults to 15 days and is not replicated; long-term storage through remote write to a system such as Grafana Mimir adds infrastructure cost |
| Grafana database and load balancing (recurring) | Not applicable | MySQL 8.0 or later or PostgreSQL 12 or later for production and high availability, plus a load balancer in front of two or more Grafana servers |
| Implementation and OpenTelemetry instrumentation (one-time) | Existing OTLP exporters can often be repointed; agent-based APM work is a one-time task | Collector, exporter and service configuration, plus integration work, paid to your staff or an implementation partner such as DeployOpen under a written scope |
| Dashboard and alert rebuild (one-time) | NRQL dashboards and alert conditions already exist in New Relic | No automated converter; NRQL queries and alert conditions must be rewritten as PromQL or LogQL and rebuilt in Grafana and Alertmanager |
| Upgrades, patching and support (recurring) | Included in the subscription, with vendor-managed upgrades | Grafana releases come monthly for patches and every other month for minor versions; Prometheus minor releases follow a 6-week cycle; your team or a retainer covers upgrades and security hardening |
| Internal skills and on-call (recurring) | Vendor support plus internal staff who know NRQL and the New Relic UI | Staff who run PromQL, Alertmanager, Loki, storage and backups; this is usually the largest recurring item and it grows with the number of services |
How New Relic per-GB ingest and user charges add up
New Relic bills by the gigabyte ingested, and it bills every data type the same way, so logs, traces, metrics and events all count toward the same meter. The first 100 GB ingested each month is free according to New Relic's pricing and billing documentation, which means the bill is driven by volume above that allowance. Start by pulling your current invoice and the usage reports for the last several billing periods, then split ingest by data type, by account and by the services or hosts generating the most telemetry. Without that breakdown, any model of a self-hosted replacement is guesswork, because it is the top few sources that usually drive most of the volume.
User charges are a separate line. New Relic has three billable user types, Basic, Core and Full platform, and your contract decides how many people fall into each. Confirm which user type each engineer, SRE, support analyst and manager holds, and whether read-only stakeholders are counted as billable users. Core Compute is the consumption-based option, which New Relic describes as offering unlimited users with charges based on queries, alerts and API calls. If your team is considering it, ask New Relic to show how your current query and alert volume would map to that model, and ask whether Data Plus is required for the features you use, because Data Plus changes what is billed and what you can export.
What moves the comparison most
Six inputs decide whether a self-hosted Grafana and Prometheus stack costs less than New Relic for your team. Each one changes a different cost line, so size them before you request a quote. Several of them are also the reasons a single node or a single server stops being enough.
Telemetry volume in GB
New Relic bills by GB ingested regardless of data type, after 100 GB per month free. Self-hosted cost follows storage and compute for each signal type: metrics in Prometheus, logs in Loki on object storage, and traces in Jaeger. Measure ingest per signal today, because high-cardinality metrics and verbose logs drive storage and query load in different ways. Ask your New Relic account team for a per-signal breakdown from your usage reports.
Number and type of users
New Relic has three billable user types: Basic, Core and Full platform. Grafana, by contrast, has no per-user line in your self-hosted cost, but its authentication features depend on edition. LDAP, generic OAuth, Entra ID, Okta and similar providers work in all editions, while SAML, team sync and SCIM are Enterprise or Cloud only. Count viewers, editors and admins separately, and confirm which identity features you need before choosing a path.
Retention period
Retention is one of the largest levers on storage cost. Prometheus keeps local data for 15 days by default and can be configured by time or size, so longer history means remote write to external long-term storage. Loki keeps logs indefinitely until retention is enabled in the compactor. Decide retention per signal and per environment, and confirm whether auditors or incident reviews need data beyond the default window.
Environments and clusters
Each additional environment or Kubernetes cluster adds scrape targets, collectors, storage paths and dashboards to maintain. New Relic bills the same way whether you run one account or many, but a self-hosted stack multiplies its footprint per environment. Decide early whether to run one central backend fed by OpenTelemetry Collectors or one stack per cluster, because that choice sets the infrastructure and the upgrade workload.
Availability requirements
Availability design changes the bill more than most teams expect. A single Prometheus server is not clustered or replicated, so it needs a managed recovery plan or a long-term storage layer. Grafana high availability needs two or more active-active servers behind a load balancer, sharing a MySQL or PostgreSQL database, and alerting needs extra configuration to avoid duplicate notifications. Each node, database and load balancer is a recurring cost, so state your uptime target in writing before you price the stack.
Skills already on staff
The largest recurring cost in a self-hosted stack is often staff time, not hardware. Your team needs Prometheus and PromQL, Grafana provisioning, Loki storage tuning, OpenTelemetry Collector configuration and on-call ownership for upgrades. Grafana's minor releases come every other month and patch releases at least monthly, so someone must own that cycle. Inventory current skills honestly, then decide what to train, hire or contract out.
How to build the comparison with your own numbers
This sequence turns New Relic's invoice and your current telemetry into a like-for-like monthly and one-time cost model against a self-hosted Grafana and Prometheus stack, so both sides cover the same period and the same workloads.
Export current ingest and user counts
Pull the last several months of data ingest by source and the number of users by billable type from your New Relic account. Use the usage and billing views in New Relic's pricing and billing documentation to confirm how ingest is measured, then note the 100 GB monthly free allowance that applies to your account. Separate APM, infrastructure, logs and any browser or session data, because each source drives a different storage and retention model later. The output is a table of GB per month by data type and a count of users by type, with the period and export date recorded.
Confirm which features drive the bill
Identify whether your account is on a plan with per-user charges, Data Plus, or Core Compute with consumption pricing, since each changes what you pay for. Ask your New Relic account team in writing to confirm the current rate for each line item and any committed-use terms. Record which NRQL queries, alert conditions and API calls your teams depend on, because a consumption-based option bills on those. The output is a written list of billable components with the rate source for each.
Model Prometheus and Loki storage from retention
Convert the ingest volumes into stored volumes by applying the retention you need. Prometheus keeps local data in two-hour blocks with a default retention of 15 days, so any longer metric history needs remote write to external long-term storage, which you must cost separately. Loki applies retention only when the compactor setting is enabled, and its documented object stores are Amazon S3, Google Cloud Storage and Azure Blob Storage for production. Estimate object storage per month from your log volume and chosen retention, and record the compression and index assumptions you used. The output is a storage line for each backend with its retention setting noted.
Size Grafana and Prometheus hosts
Use Grafana's installation guidance as the starting point for the Grafana server, noting that a small deployment under 25 concurrent users is documented at 2 cores and 2 to 4 GB of RAM. Size Prometheus from your active series count and scrape interval, and confirm sizing with the Prometheus storage documentation, since local storage is single-node and not replicated. Add the database for Grafana configuration, which must be MySQL 8.0 or later or PostgreSQL 12 or later for production. If you need high availability, price two or more active-active Grafana servers behind a load balancer. The output is a host list with CPU, memory, disk and the cloud or data center cost of each.
Add Alertmanager, Loki components and reverse proxy
Add the components that are easy to forget. Alertmanager handles grouping, inhibition and silences, and in a cluster Prometheus should point at every Alertmanager instance rather than a load balancer. Loki has no built-in authentication, so price an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Include Grafana Alloy or the OpenTelemetry Collector for shipping, plus TLS certificates and backup storage. The output is a complete component inventory that matches the architecture you plan to run, so no line is missing from the total.
Price staff hours for upgrades and on-call
Estimate the recurring operations work in hours per month, then price it with your own loaded staff rates. Include Grafana upgrades, which arrive as patch releases at least monthly and minor releases every other month, and Prometheus minor releases, which begin every 6 weeks and stop receiving bug fixes after that period. Add Prometheus long-term support tracking, Loki and Grafana patching, backup restore tests, and on-call coverage for the alerting path. Compare this with what you pay New Relic for support and operations today. The output is a monthly labor line with the assumptions written beside it.
Add one-time migration and rebuild effort
Count the one-time work separately from the monthly costs. This includes replacing New Relic agents or repointing existing OTLP exporters to a Collector, rebuilding NRQL dashboards and alert conditions as Grafana dashboards and rules, translating log queries to LogQL, and running both backends in parallel before cutover. Also price the export of historical data, since New Relic's export tooling has its own requirements. Ask any outside implementer for a written fixed-scope quote covering every item, and request written quotes for each outside line item in the model. The output is a one-time cost sheet with a line for each dashboard group, alert set and data source.
Compare totals over the same period
Place both models side by side over an identical period, such as twelve months, and include recurring and one-time costs for each. Show New Relic's ingest, user and plan charges alongside the self-hosted infrastructure, storage, labor and external quotes. Run both backends in parallel for a defined window before deciding, and compare actual ingest, query behavior and alert accuracy against the model. The output is a single comparison sheet with the assumptions for each cell and the parallel run results used to confirm or correct them.
What the self-hosted stack costs to run
The recurring cost of a self-hosted Grafana and Prometheus stack sits mostly in storage design and staff time, not in the software license, because Prometheus, Grafana and Loki are all open source and carry no paid edition of the project itself. Start with Prometheus local storage. Its time series database is stored in two-hour blocks with a write-ahead log, the default retention is 15 days, and local storage is not clustered or replicated. Anything you need beyond that window, or any high availability requirement, means remote write to a long-term store such as Grafana Mimir, which is AGPL-3.0-only and adds its own compute and object storage bill. Ask your team to confirm the retention period each compliance or incident process needs before sizing disks.
Logs are a separate cost line. Loki's monolithic mode is documented for up to about 20 GB of logs per day, and simple scalable mode, documented for approaching 1 TB per day, is being deprecated and will be removed with Loki 4.0, so a growing log volume may force a move to microservices mode. Loki keeps chunks and its index in object storage, and retention is disabled until retention_enabled is set in the compactor configuration, so logs persist indefinitely by default. Grafana high availability needs two or more active-active servers behind a load balancer on a shared MySQL or PostgreSQL database, and Alertmanager needs its --cluster flags so that Prometheus can reach every instance. Each of these is a recurring compute and database cost.
Upgrades drive staff time more than most readers expect. Grafana minor releases are supported for 9 months, and the last minor release of a major version for 15 months, with patch releases at least monthly. Prometheus minor releases receive no bug fixes after six weeks, while its long-term support line receives fixes for one year. Budget a recurring upgrade cycle for each component and record who owns it, including Alertmanager and the Loki components. When you ask a partner or internal team for a quote, request the upgrade and patch calendar, the on-call coverage for storage and alerting failures, and the backup and restore test schedule as separate line items so they can be compared with your current New Relic bill.
Questions buyers ask before comparing cost
Is self-hosting Grafana and Prometheus always cheaper than New Relic?
No. Self-hosting removes the per-GB ingest and per-user charges, but it moves those costs onto compute, storage, retention, upgrades and the staff who run the stack. New Relic bills data by GB ingested regardless of type and includes 100 GB ingested per month free, so a small team may find the hosted bill modest. Model your own volume, retention period and user count, then compare that total with infrastructure and the hours your engineers will spend on operations. The answer often depends on data volume and how long you keep it.
What drives the cost of a self-hosted Prometheus and Loki stack?
Four components matter most. Compute for Prometheus, Grafana and Loki scales with series count, query load and log volume. Storage depends on retention: Prometheus keeps 15 days by default, and Loki keeps logs indefinitely until retention is enabled in the compactor. High availability adds a second Grafana server and a MySQL or PostgreSQL database, and Loki production setups usually use object storage such as S3, Google Cloud Storage or Azure Blob Storage. Staff time for upgrades, backups and on-call response is the component most teams underestimate.
How long does it take to rebuild dashboards and alerts in Grafana?
The effort depends on how many New Relic dashboards, NRQL queries and alert conditions are in use, and no automated converter exists for them. Each query must be rewritten, for example from NRQL to PromQL or LogQL, and each alert must be recreated with its thresholds and notification routing. Grafana provisioning can store the rebuilt dashboards and alert rules as YAML or JSON files, which makes the work reviewable and repeatable. Ask any implementation partner to inventory dashboards and alerts first, because that inventory sets the scope and timeline.
Can our own team run this migration without outside help?
A team with strong Kubernetes, Linux and observability experience can run it internally, particularly if it already instruments applications with OpenTelemetry. Outside help is most useful for the parts that are easy to get wrong: high-availability Grafana with alerting that avoids duplicate notifications, Loki retention and object storage design, Alertmanager clustering, and security hardening. A fixed-scope engagement can cover planning, implementation, hardening, backup and documentation, while your team keeps ownership. Decide which parts you will own before you ask for a quote.
What skills does a self-hosted observability stack require?
Plan for skills in four areas. Engineers need OpenTelemetry instrumentation and Collector configuration, PromQL and LogQL for queries, and Linux or Kubernetes administration for the servers. The operations side needs experience with backups, database management for Grafana, upgrades and capacity planning. Security work covers authentication, since Grafana's SAML and SCIM options are limited to Enterprise and Cloud, and Loki requires an authenticating reverse proxy in front of it. Ask whether your team already has these skills or whether training or outside support is needed.
What recurring work follows the launch of a self-hosted stack?
Recurring work includes applying Grafana patch releases, which Grafana says arrive at least monthly, and planning minor upgrades, which come every other month. Prometheus releases a new minor version every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks, so many teams choose the long-term support line instead. Loki's simple scalable deployment mode is being deprecated and will be removed in Loki 4.0. Other recurring work includes reviewing retention, rotating credentials, testing backups and reviewing alert noise.
What should we ask for in a quote for a self-hosted migration?
Ask for a written scope that lists each component, such as Prometheus, Grafana, Loki, Alertmanager, Collector deployment and Jaeger, along with the dashboards and alerts to be rebuilt. Request the deliverables, the acceptance criteria, what happens during parallel running, and who owns each runbook. Ask how backup, upgrades, hardening and documentation are included, and whether ongoing support is offered as a separate retainer. Confirm which infrastructure is supplied by your team and which by the implementer. DeployOpen does not publish a price list and quotes follow from the written scope.
Do we need to stop sending data to New Relic during the migration?
No, and most teams avoid stopping it. New Relic, Datadog and Dynatrace each document OTLP ingestion, so applications instrumented with OpenTelemetry can send the same telemetry to New Relic and a self-hosted backend in parallel. This lets you compare dashboards and alerts before cutover and keeps the commercial service available as a reference. Confirm with your New Relic account team how parallel running affects your billed volume before you start.
What the one-time rebuild of dashboards and alerts involves
NRQL dashboards and alert conditions do not convert automatically. Each dashboard widget and alert condition written in NRQL has to be rebuilt by hand as a Grafana panel and a Prometheus or Loki alert rule, and the queries themselves must be translated into PromQL for metrics or LogQL for logs. Start by exporting an inventory from New Relic: every dashboard, its widgets, every alert condition, its thresholds, its notification policy and its owner. Mark which items are still used. Many dashboards are created once and never opened again, and retiring them is usually the cheapest saving in the whole project. No supplied fact gives a rebuild duration, so estimate effort from your own counts, weighting complex joins, faceted queries and multi-account views more heavily than simple single-metric panels. Ask any implementation partner to price the work from that same inventory.
Once rebuilt, keep the assets as code so they do not have to be rebuilt again. Grafana provisioning loads data sources, dashboards and alerting resources from YAML or JSON files at startup, and Grafana documents further options such as Terraform and Git Sync. Store those files in version control, review changes the way you review application code, and confirm which provisioning method your Grafana version and team support before you commit to one. Expect the query languages to differ in ways that affect the design: PromQL works on label-based time series, while LogQL filters streams selected by labels and then parses or aggregates log lines. NRQL event-based queries do not map one to one, so some dashboards will need to be redesigned rather than copied. Plan label naming before you migrate, because Loki stream labels in particular are costly to change later.
How DeployOpen scopes a fixed-scope implementation
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a New Relic cost review that ends in Grafana and Prometheus, we start from a written, fixed scope so cost components, rebuild work and cutover steps are agreed before any build begins.
How we scope
- Inventory which New Relic products, data types and user roles drive your current bill, including ingest, Data Plus and user tiers
- Map each telemetry source to an OpenTelemetry pipeline, a Prometheus scrape target or a Loki log path
- Agree in writing which dashboards, alert conditions and retention settings are in scope for the rebuild
- Set out the cost model for compute, storage, retention and staff time so you can compare it with your New Relic invoices
How we build
- Deploy Prometheus, Grafana, Alertmanager and any Loki or Jaeger components you chose, sized to the scope agreed in writing
- Configure OTLP pipelines so the same telemetry can reach New Relic and the self-hosted stack in parallel during migration
- Rebuild dashboards and alert rules as provisioned, version-controlled files so the setup can be reviewed and reproduced
- Test alert routing, high availability and authentication against the requirements in your written scope before cutover
How we hand over
- Document the architecture, retention settings, upgrade steps and the list of rebuilt dashboards and alerts with their owners
- Provide a runbook for backups, Grafana database choice, Alertmanager clustering and reverse proxy authentication in front of Loki
- Walk your platform and on-call teams through daily operation, alert triage and how to add new data sources
- Record a clear cutover checklist and the decommissioning steps for New Relic agents, exporters and data retention
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the implementation
- Plan upgrades against the Grafana and Prometheus release cycles so patches and end-of-life dates are tracked
- Ask for the retainer scope in writing, including who responds to incidents and what changes trigger a review
- Confirm with your own auditors which monitoring evidence they need, since DeployOpen prepares controls and evidence but does not issue audit reports
