OpenObserve as a New Relic Alternative
New Relic is a long-established APM and observability platform. For teams running at scale, the per-user pricing, the proprietary query language (NRQL), and the SaaS-only model are the most common reasons to evaluate alternatives. This page covers how OpenObserve compares and what changes if you migrate.
Why Teams Consider Moving Off New Relic
Per-user pricing
New Relic's pricing model combines ingest with per-user fees, with the higher tiers charging several hundred dollars per user per month. For an org with even a moderate engineering team, the per-seat line item often outpaces the ingest line item.
OpenObserve charges $0 per seat. Pricing is purely ingest-based, so adding engineers to the platform is free.
NRQL, a proprietary query language
NRQL is specific to New Relic. Every dashboard, alert condition, and saved query is written in NRQL, so leaving New Relic means rewriting them.
OpenObserve uses SQL for logs and traces and PromQL for metrics. Both are widely known and portable.
Vendor lock-in
New Relic uses proprietary agents and a proprietary data model. Migrating off the platform requires re-evaluating your instrumentation strategy.
OpenObserve is OpenTelemetry-native end to end. Instrumentation done with OTel SDKs and the OTel Collector ports cleanly to any backend, so you're never locked into OpenObserve either.
SaaS-only
New Relic is delivered as a cloud service only. For workloads with data-residency, air-gap, or regulated-environment requirements, that can be a blocker.
OpenObserve runs as self-hosted (single binary or Helm chart) or OpenObserve Cloud. Self-hosted means raw telemetry stays in your bucket (S3, GCS, Azure Blob, MinIO, or local disk).
APM agent overhead
The New Relic APM agents are proprietary, language-specific, and heavier than the OpenTelemetry SDK + Collector combination.
Feature Comparison
| Feature | New Relic | OpenObserve |
|---|---|---|
| Logs | Yes | Yes, real-time analytics without traditional indexing overhead |
| Metrics | Yes | Yes, full Prometheus / PromQL compatibility |
| Traces / APM | Yes | Yes, first-class OpenTelemetry support |
| Dashboards | Yes | Yes, prebuilt dashboards, UI builder, custom mode |
| Alerts | Yes | Yes, SQL/PromQL-based alerting |
| Frontend monitoring (RUM) | Yes | Yes |
| Pipelines / data transforms | Yes | Yes (Vector Remap Language) |
| Query language | NRQL (proprietary) | SQL + PromQL |
| Pricing model | Per user + per GB ingest | Ingest-based only |
| OpenTelemetry native | Partial | Full |
| Self-hosted option | No | Yes |
| Monthly per-seat cost | Per-user fees on higher tiers | $0 |
| Bring your own storage | No | Yes (S3, GCS, Azure Blob, MinIO) |
| Open source | No | Yes |
Architectural Differences
| Layer | New Relic | OpenObserve |
|---|---|---|
| Ingest agents | New Relic APM agents (per language) + Infrastructure agent | OpenTelemetry Collector, OTel SDKs, Fluent Bit, Vector |
| Wire protocol | Proprietary New Relic ingest APIs | OTLP, Prometheus Remote Write, Loki Push API, JSON over HTTP |
| Storage | New Relic-managed (opaque) | Apache Parquet on object storage (S3/GCS/Azure/MinIO/local) |
| Query | NRQL to New Relic backend | SQL/PromQL to stateless queriers reading Parquet |
| Visualization | New Relic One | OpenObserve UI (built-in) |
| Deployment | SaaS only | Self-host or OpenObserve Cloud |
Data Ownership
In New Relic, your raw telemetry lives on their cluster. You can query it through their UI and API, but you can't cheaply backfill, re-process, or join it against the rest of your data.
In OpenObserve, raw events live in your object storage as Parquet. You can query it from OpenObserve, but the data is also accessible directly from any tool that reads Parquet (Athena, Spark, DuckDB, Trino), so it stays usable beyond the observability use case.
What Stays the Same
Migrating off New Relic does not require re-instrumenting your applications when you've already adopted OpenTelemetry:
- OTel SDKs in your code keep emitting OTLP. Only the exporter endpoint changes.
- OTel Collectors keep their receivers and processors. Swap the
newrelicexporter forotlphttppointed at OpenObserve. - Prometheus scrapers keep working unchanged. Add an OpenObserve
remote_writetarget.
If you still rely on New Relic APM agents, you can either keep them temporarily (with a Collector translation layer) or move incrementally to OpenTelemetry SDKs, language by language.
Migration Shape
A typical move off New Relic runs in three steps:
- Point collectors at OpenObserve. Update OTel Collector exporter endpoints to OpenObserve. No re-instrumentation required for apps already using OTel. Run dual-write for a window to validate.
- Rebuild dashboards and translate alerts. Convert NRQL queries to SQL/PromQL. The OpenObserve AI Assistant handles the bulk of NRQL to SQL/PromQL translation automatically.
- Cut over and optimize. Shift production workloads gradually, starting with non-critical services. Validate retention and query latency before decommissioning the New Relic side.
Teams already on OpenTelemetry can start ingesting into OpenObserve within hours. Full cutover usually lands in days to a few weeks, dominated by dashboard and alert rebuild rather than data movement.
Need Help?
- Join our Community Slack
- Or Contact support
Last updated on
OpenObserve vs Splunk
How OpenObserve compares to Splunk on cost, query language, architecture, and operational complexity, with migration guidance for teams moving off Splunk.
OpenObserve vs Datadog
How OpenObserve compares to Datadog on pricing, custom metrics fees, vendor lock-in, OpenTelemetry support, and data ownership, with migration guidance.