New Relic or self-hosted Grafana and Prometheus: which fits your team
For most teams with a renewal or an ingest bill that keeps growing, New Relic fits best when APM depth and fast time to value matter more than controlling the backend, and self-hosted Grafana and Prometheus fits best when metrics volume is predictable, many people need query access, and someone on staff can own storage, upgrades and availability. The decision turns on five things: data volume, how many users need query access, how much APM depth you actually require, how long you must keep data, and who will run the backend day to day.
New Relic fits when you want a managed backend with broad APM out of the box and your team would rather not operate storage or query tiers. Its per-GB ingest model rewards keeping telemetry lean, and the New Relic pricing and billing documentation describes the 100 GB monthly free allowance and the Core Compute option with unlimited users. Grafana and Prometheus fits when metrics dominate your needs, retention must be set by you, and dashboards must be open to many engineers without a per-user line item. Prometheus stores data locally with a default retention of 15 days, is not clustered or replicated, and needs a remote storage system such as Mimir for longer history, so confirm that your team can own that design before committing.
Confirm three things before choosing: whether your current APM depth (distributed traces, service maps, code-level profiling) has a working equivalent in Jaeger and Grafana for your languages, whether a named engineer can carry on-call duty for the backend, and how long compliance requires data to be kept. Because New Relic supports OTLP ingest, instrumenting services with OpenTelemetry keeps the choice reversible: the same telemetry can flow to either backend while you compare them.
Which scenarios favor New Relic and which favor Grafana and Prometheus
This table maps common operating situations to the platform that usually fits them better and the condition that decides it. Read each row against your own constraints, since the deciding condition is often the same across teams but the answer is not. The main takeaway is that the choice follows team capacity, data location, telemetry shape and how many people need access, not a general ranking of either product.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Small platform team with many read-only stakeholders | New Relic, if per-user cost is the main concern, or Grafana and Prometheus if viewer access is broad | Check New Relic's current user types and whether Core Compute, which offers unlimited users on consumption pricing, fits your query and alert volume. Grafana viewer access is governed by your own deployment and authentication setup. |
| Regulated team that must keep telemetry in its own data center | Grafana and Prometheus | Self-hosting keeps metrics and dashboards inside your facilities. Confirm with New Relic's regional options whether an EU region satisfies your residency rules, since existing account data is not moved between regions. |
| Team with mostly Kubernetes and infrastructure metrics | Grafana and Prometheus | Prometheus scrapes metrics from service discovery and is queried with PromQL, which fits Kubernetes-style targets. Plan for single-node local storage and add remote storage if retention needs exceed the default 15 days. |
| Team needing managed APM with little in-house operations capacity | New Relic | A hosted backend removes storage sizing, upgrades and high availability work from your staff. Self-hosting requires someone to run Prometheus, Grafana's database and Alertmanager clusters. |
| Team with high-cardinality or long-retention needs | Depends on design, often Grafana with a long-term store such as Mimir | Prometheus local storage is not clustered or replicated, so long retention usually means remote write to external storage. Confirm New Relic's retention and data plan terms for your volumes. |
| Team already instrumenting with OpenTelemetry and wanting to keep options open | Either, run in parallel | Because New Relic accepts OTLP natively, you can send the same telemetry to both backends during evaluation. Confirm which OTLP signals your team relies on before cutover. |
| Team whose main need is deep, vendor-curated APM features and language-specific agents | New Relic | Commercial agents and curated APM views are a strong draw. Assess which features your engineers actually use, then confirm the open-source equivalents cover them through OpenTelemetry and Jaeger. |
How data location, hosting and identity differ on each side
Telemetry can carry customer identifiers, internal hostnames and user activity, so where it lands and who can reach it matters as much as the features. New Relic keeps data in a hosted account, while a self-hosted Grafana and Prometheus stack sits wherever you place it. The cards below set out the decisions and checks on each side.
Where telemetry is stored
In New Relic, telemetry is stored in the hosted platform, and the region your account uses determines where it sits. In a self-hosted stack, Prometheus keeps samples in a local time series database on the server that runs it, and its storage docs describe that storage as single-node by default, not clustered or replicated. Ask New Relic which regions your account can use and where backups are held. Then decide where Prometheus volumes and any long-term store will run, and confirm each location against your residency rules before data flows.
Hosting placement and ownership
New Relic is operated by the vendor, so your team controls account configuration and the OTLP endpoint your collectors send to, while the vendor runs the facility. A self-hosted Grafana, Prometheus and Jaeger stack runs in your cloud account, data center or air-gapped network, which means your team also owns patching, backups, network paths and failover. Map who holds the hosts, the encryption keys and the backup copies on each side. Write those owners into the architecture document before cutover so that gaps surface early.
SSO support by Grafana edition
Grafana's authentication docs state that LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT work in every edition. SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. If your identity provider requires SAML or you need SCIM deprovisioning, the open-source edition will not cover that alone. Check how your identity provider sends group membership, because team sync is one of the Enterprise-only features.
Access controls and hardening settings
Grafana's security hardening docs recommend secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, authentication on the metrics endpoint and domain verification against DNS rebinding. Prometheus's security model leaves authentication and transport protection to the operator, so its HTTP endpoints and Alertmanager need network restrictions or an authenticating reverse proxy. Test that unauthenticated requests to metrics and query endpoints fail. Then map New Relic user roles to Grafana teams and folders so access carries over.
Compliance evidence you still own
Hosted vendors usually publish their own assurance reports for the service, but those describe the vendor's controls, not yours. With a self-hosted stack, your team must evidence access reviews, change records, backup restores, log and metric retention settings and key management for every component. DeployOpen can prepare these controls and evidence inside your environment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that assessment, so ask your assessor early which evidence they expect.
Capabilities side by side: APM, query language, retention, users and licensing
This table compares New Relic with a self-hosted stack of Prometheus for metrics, Grafana for dashboards and alerting, and Jaeger for traces, across APM, query language, retention, licensing and high availability. Read each row as what the platform provides on its own and what depends on a companion tool or on your own operations. The main takeaway is that the open-source stack removes per-GB and per-user fees in exchange for components you install, size, upgrade and run.
| Capability | New Relic | Self-hosted Grafana and Prometheus |
|---|---|---|
| APM and distributed tracing | Hosted APM agents and UI in one platform; confirm language and framework coverage for your services | Traces need Jaeger (Apache-2.0) or another OpenTelemetry-compatible backend; there is no bundled APM agent suite |
| Metrics query language | NRQL, New Relic's proprietary query language for metrics, events and logs | PromQL, the Prometheus query language, used by Grafana panels and alert rules |
| Logs | Native log management, billed on ingested GB like other data types | Requires Grafana Loki (AGPL-3.0-only) or another log store, plus a collector to ship logs |
| Alerting | Alert conditions and notification channels inside the platform | Grafana alerting for dashboards; Prometheus rules routed through Alertmanager, which can run as a cluster |
| Dashboards and as-code | Dashboards built in the New Relic UI | Grafana dashboards with provisioning from YAML or JSON files, plus Terraform and Git Sync options |
| OTLP ingest | Native OTLP endpoint on ports 443, 4317 and 4318, recommended for OpenTelemetry data | Prometheus accepts OTLP metrics at its OTLP path when started with the OTLP receiver flag; traces and logs go to other backends |
| Retention control | Set by your account and data plan; confirm retention periods in your contract | Prometheus defaults to 15 days, set by time or size; longer history needs remote write to storage such as Grafana Mimir |
| User licensing | Basic, Core and Full platform user types; Core Compute offers consumption pricing with unlimited users | No per-user fee in the open-source edition; SAML, SCIM and team sync are Enterprise or Cloud features |
| License terms | Proprietary hosted service | Prometheus Apache-2.0, Grafana AGPL-3.0-only since 2021, Jaeger Apache-2.0 |
| High availability | Operated by New Relic as part of the hosted service | Grafana needs two or more nodes with MySQL or PostgreSQL; Grafana Live has HA limits; Prometheus local storage is not clustered |
How NRQL and PromQL answer the same questions differently
NRQL and PromQL answer the same operational question with different data models. NRQL is New Relic's query language across telemetry types: it reads events, metrics, traces and logs from one store and can join them in a single statement. PromQL queries Prometheus time series, where each series is identified by a metric name and a set of labels, and it works on numeric samples rather than raw events. Consider an illustrative question, "what fraction of checkout requests failed in the last five minutes?" In NRQL, a team would write a query against the Transaction event type, using a filter on the error attribute and a percentage aggregation. In PromQL, the same team would divide a rate of an error counter by a rate of a request counter, both filtered by a service label and a status label, and then wrap the result in an alert expression. The NRQL version is shorter to write, but the PromQL version only works if the team has instrumented counters with the labels it needs. Before translating a single dashboard, list the queries your engineers run most often and check whether each one depends on New Relic's event schema.
APM depth is the part of this comparison that needs the most honest scoping. New Relic bundles APM agents, service views, transaction traces, error inbox and service maps into one product, and those views are populated without much setup. The open-source path combines OpenTelemetry instrumentation, Jaeger for distributed traces and Grafana dashboards for metrics, and the team builds the equivalent views itself. Service maps, error grouping and the deploy-level comparisons that many APM users rely on are not provided as a finished feature set, so they need to be assembled from traces, span metrics and dashboard panels. Ask your platform and application teams to list the New Relic APM views they open in an ordinary incident, such as service maps, transaction breakdowns, database call analysis or error grouping. Each item on that list becomes a line in the migration scope, and that list, not a general feature comparison, is what should drive any estimate of effort.
What running your own Prometheus and Grafana backend involves
A self-hosted Prometheus and Grafana stack replaces New Relic's hosted backend with components your team installs, upgrades and keeps running. The cards below cover the decisions and recurring tasks that connect storage, alerting, the Grafana database, release cadence and day-two operations, so you can size the staff effort before you commit.
Prometheus local storage and retention
Each Prometheus server writes to a local time series database with a write-ahead log, and its default retention is 15 days. Local storage is not clustered or replicated, so a single server failure creates a gap in history unless you plan for it. Decide early how long you must keep metrics, then configure remote write to a long-term store and confirm who owns that store's capacity and backups. New Relic keeps retention on the vendor side under your data plan, so this decision moves to your team.
Alertmanager clustering and HA wiring
Alertmanager groups, inhibits and silences the alerts Prometheus sends. For high availability it runs as a cluster using its cluster flags, and Prometheus must be pointed at every Alertmanager instance rather than at a load balancer. Test this wiring with a deliberate instance failure and confirm that notifications still arrive once, not twice. Your on-call routing depends on this path, so treat it as production infrastructure with its own monitoring.
Grafana database and high availability
Grafana stores configuration in SQLite by default, but the installation docs state that SQLite does not scale for production. Production and high availability need MySQL 8.0 or later or PostgreSQL 12 or later. High availability uses two or more active-active Grafana servers behind a load balancer, and alerting needs extra configuration to avoid duplicate notifications. Confirm which Grafana Live features you need, since the docs list limitations in HA mode, and plan database backups alongside the servers.
Grafana release cadence and support windows
Grafana ships major releases once a year, usually in April or May, minor releases about every other month, and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor of a major version for 15 months. Someone must schedule upgrades inside those windows, test dashboards and alert rules against each release, and roll changes across every HA node. Budget this as a standing task, not a project, and track it against the support calendar.
Prometheus release cycle and LTS line
Prometheus minor releases start a new cycle every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks. For a stability-focused deployment, the long-term support line receives bug fixes for one year. The current LTS line is 3.13, released July 1, 2026 and supported until July 31, 2027. Choose between tracking minor releases and staying on LTS, and record the end-of-support date for whichever line you pick so upgrades are scheduled before it passes.
Backups, on-call and capacity planning
Backups for Prometheus data, Grafana's database and Alertmanager state need separate restore tests, because a backup that has never been restored is not evidence of recovery. On-call coverage must include the monitoring stack itself, since nobody is notified when the monitor fails. Capacity planning tracks series count, ingest rate and disk growth against your retention target. Staff need Linux, Kubernetes or Docker, PromQL and database administration skills, and these tasks recur every month rather than ending at go-live.
Where the cost of each option comes from
On the New Relic side, the bill is driven by data ingested, measured in GB regardless of data type, with the first 100 GB per month free according to New Relic's pricing and billing documentation. Every GB above that allowance is billed, so the cost moves with how many traces, metrics and logs your services emit and how long your teams keep high-cardinality signals. A second line item is user type: New Relic has three billable user types (Basic, Core and Full platform), and each user is charged according to the type they hold. Core Compute is the consumption option that offers unlimited users, with charges based on queries, alerts and API calls. Before comparing, ask New Relic or your reseller which option your account would use, and pull a month of ingest by source and query volume from your own account so the comparison uses your numbers.
On the self-hosted side, Prometheus has no license fee, so the recurring cost is infrastructure and people. Compute for Prometheus, Grafana, Alertmanager and the Collector scales with active series and query load. Storage is sized to retention: Prometheus defaults to 15 days of local data, and its storage documentation says local storage is not clustered or replicated, so longer retention or high availability means remote storage such as Mimir (AGPL-3.0-only) or another external system, each with its own hosts and disks. Network costs appear when telemetry crosses zones or regions. If you choose Grafana Enterprise or Grafana Cloud, those are priced separately: the Grafana pricing page lists a Pro tier starting with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a 25,000 US dollar yearly minimum. Staff time for upgrades, on-call and alert tuning is usually the largest recurring item, and it should be costed as a named role, not a rounding error.
One-time costs are the migration itself: repointing OpenTelemetry exporters, rebuilding NRQL dashboards and alert conditions as PromQL and Grafana rules, and running both backends in parallel until cutover. Recurring costs are infrastructure, support, upgrades and on-call. When requesting a quote from DeployOpen or any other implementer, ask for a written scope that lists the services and environments in scope, the current and projected data volumes per signal, the retention target for each signal, the number of dashboards and alert conditions to rebuild, the high availability requirement, the authentication model, and which items are one-time and which are retainer based. Ask for the assumptions behind any sizing, so you can check them against your own telemetry.
How a move from New Relic to Grafana and Prometheus runs
The sequence starts with an inventory of what New Relic currently receives and ends with decommissioning, so each step produces evidence that the self-hosted stack matches what the team relies on. No single tool converts a New Relic account automatically, so the work is planned and checked by people who know the workloads.
Inventory agents, exporters, dashboards and alerts
List every service sending telemetry to New Relic, noting whether it uses a New Relic language agent, the OpenTelemetry SDK with OTLP export, or an infrastructure agent. Export the dashboards, alert conditions, notification channels and the NRQL queries behind them, and record which teams own each one. Mark which items are used during incidents and which are historical. The output is a signed-off inventory that the team can use to measure parity later.
Deploy the Collector, Prometheus, Jaeger and Grafana
In the client's own cloud account, data center or air-gapped network, install the OpenTelemetry Collector, Prometheus, Jaeger and Grafana, with Alertmanager for routing. Because Prometheus local storage is single-node and not replicated, decide early whether long-term metrics need remote storage and whether Grafana runs in high availability with MySQL or PostgreSQL. Configure authentication through the identity provider your organization uses. The check is that each component starts, passes health checks and is reachable only from the networks that need it.
Dual-send telemetry to both backends
Add a second OTLP exporter in the Collector or the application configuration so that the same traces, metrics and logs flow to New Relic and to the self-hosted stack. Keep New Relic in place as the reference while the new stack fills. Compare sample counts, service names, resource attributes and span relationships between the two backends, and fix label or attribute mismatches before anyone builds on them. The check is a documented set of services where the two backends agree.
Rebuild dashboards and map NRQL to PromQL
Recreate dashboards in Grafana service by service, starting with the ones used in incidents. Translate each NRQL query by its intent, since NRQL and PromQL differ in how they aggregate and filter, and metric names will change when OpenTelemetry semantic conventions are applied. Trace views move to Jaeger, and log queries may need a separate log store. The output is a dashboard list where each panel has a named owner and a note on any query that could not be reproduced exactly.
Validate alert parity before cutover
Rebuild each alert condition as a Prometheus alerting rule routed through Alertmanager, then test it against known conditions such as a forced error rate or a stopped scrape target. Confirm that grouping, silences and inhibition behave as intended, and that Alertmanager runs as a cluster if high availability is required, with Prometheus pointed at every instance. Record which alerts fire in both systems and explain each difference. The check is a signed parity record that the on-call team has reviewed.
Plan the export of data already stored in New Relic
Historical telemetry in New Relic does not move with the dual-send. Decide which history must be kept for audit, post-incident review or trend analysis, and plan an export through New Relic's own export options, confirming their current limits and plan requirements in New Relic's documentation. Store exported data in an access-controlled location within your environment. The output is a retention decision for each data class and a tested export file.
Cut over and decommission New Relic
After the parity record is accepted, stop routing on-call and incident workflows through New Relic, remove its exporters from the Collector, and keep a read-only window for reference. Revoke ingest keys and user access, cancel or reduce the subscription according to the contract terms, and update runbooks to point at Grafana, Prometheus and Jaeger. The check is that no service still exports to New Relic and that the on-call team has confirmed the new runbooks in a live drill.
Questions buyers ask before choosing or hiring help
How much work does a switch from New Relic to Grafana and Prometheus take?
The work scales with the number of services instrumented, the dashboards and alert conditions to rebuild, and how much NRQL your teams rely on. A stack with a few services and a handful of dashboards is a very different job from one where every team has custom NRQL queries feeding alert policies. Start by inventorying those three counts and noting which queries use NRQL features that have no direct PromQL or LogQL equivalent, because those queries need redesign rather than translation. Ask any implementation partner to base its written scope on that inventory.
Can our own engineers run the migration without outside help?
Yes, many teams do, provided they have people who know OpenTelemetry instrumentation, the OpenTelemetry Collector, Prometheus configuration and PromQL, and Grafana administration. The skills gap is usually in operating the backend: storage sizing, upgrades, high availability and alert routing through Alertmanager. Because New Relic supports native OTLP ingest, a team can send the same telemetry to both backends during a parallel run, which lowers the risk of doing it alone. Assess your staff against those skills before deciding, and treat any gap as a scope item for a partner or for training.
How long does a migration take, and what sets the timeline?
The timeline depends on the same factors that set the scope: the number of services, dashboards and alert conditions, the amount of NRQL in use, and how many teams must sign off on changes. Parallel running, which is practical because New Relic, Datadog and Dynatrace all document OTLP ingestion, adds time but reduces cutover risk. Your change windows and the availability of service owners for validation also matter. DeployOpen does not publish durations, so ask for a timeline tied to a written scope, with milestones for instrumentation, dashboards, alerts and cutover.
What do we need to provide for a migration engagement?
Plan for access and named owners before work starts. You will typically need administrative access to the New Relic account for exporting dashboard and alert definitions, read access to the applications and hosts sending telemetry, and cloud or data center accounts where the self-hosted stack will run. Name an owner for each service, an approver for alert changes, and a sponsor for cutover decisions. Agree on test and production environments, and set change windows in advance, since re-pointing exporters and retiring alerts touches live on-call paths.
Does the open-source Grafana edition lack SSO features that compliance may require?
Grafana's open-source edition supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT, according to Grafana's authentication documentation. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your access control requirements depend on SAML or SCIM-driven provisioning, you must either accept that gap, use an identity provider that exposes one of the supported OAuth or OIDC-style options, or license Grafana Enterprise. Confirm the specific requirement with your compliance lead and your identity team before choosing the edition.
Can Prometheus keep long-term data, or do we need more storage?
Prometheus keeps data in a local time series database with a default retention of 15 days, configurable by time or size, and its storage is not clustered or replicated. For longer retention, Prometheus supports remote write and remote read to external long-term storage systems. Grafana Mimir, which is AGPL-3.0-only, is one such horizontally scalable option. Retention length, query volume and the number of series will determine the storage design, so size the backend against your actual data before you commit to a retention policy.
What does ongoing support cover under a retainer?
Ongoing support, upgrades and continuous testing are available as retainers, and their scope is set in writing. For a self-hosted Grafana and Prometheus stack, the typical areas are version upgrades, backup and restore checks, patching, alert and dashboard changes, and monitoring of the backend itself. Prometheus minor releases stop receiving bug fixes after six weeks, and LTS lines receive fixes for one year, so decide which release line you will track. Ask any provider which items are included, how changes are requested, and what response processes apply.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For New Relic vs Grafana and Prometheus, we start from your current APM, query and retention needs, then scope the self-hosted stack around them in writing before any work begins.
How we scope
- Inventory which New Relic APM, NRQL dashboards, alert conditions and log sources your teams actually depend on.
- Map each capability to Grafana, Prometheus, Jaeger or Zabbix and record the gaps in writing.
- Agree fixed scope, deliverables and timelines with your team before any work starts, and confirm the gaps you will accept.
How we build
- Deploy Grafana with a production database and Prometheus inside your own infrastructure, sized from your measured ingest.
- Configure OpenTelemetry Collector pipelines that send the same OTLP telemetry to New Relic and the self-hosted stack in parallel.
- Rebuild dashboards and alert rules in Grafana as code, then test them against your current New Relic alert behavior.
How we hand over
- Document architecture, retention settings, access controls and runbooks so your engineers can operate the stack without us.
- Provide provisioning files and configuration in your own repositories, so dashboards and data sources are reproducible.
- Walk your operations and on-call staff through alerting, upgrades, backups and the cutover checklist before New Relic is switched off.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover Grafana and Prometheus upgrades, patch cycles and backup verification against the release schedules you choose.
- Ask us in your quote to separate one-time migration effort from recurring operations, so you can compare it with New Relic billing.
