New Relic Pioneered APM. The Telemetry Namespace It Built Is Centrally Indexed.

Vendor and product reality

New Relic, Inc. was acquired by Francisco Partners and TPG in late 2023 in a roughly six-and-a-half-billion-dollar take-private transaction, ending its run as a public company but preserving the product roadmap. The company employs several thousand engineers and operates ingest infrastructure across multiple cloud regions in North America, EMEA, and APAC. Its flagship platform — New Relic One — is sold under a usage-based pricing model that bills by gigabytes ingested into NRDB plus per-user seats for full platform access. Customers include a substantial fraction of the Fortune 500 and a long tail of mid-market SaaS vendors who rely on the agent-based instrumentation New Relic ships for Java, .NET, Node, Python, Ruby, Go, PHP, and a range of mobile and browser runtimes.

The product itself is genuinely strong. NRQL provides a SQL-adjacent query surface over a wide-column telemetry store optimized for time-series and high-cardinality attribute queries. Entity synthesis automatically constructs an entity graph from incoming telemetry, linking services, hosts, containers, browsers, and mobile apps through inferred relationships. Lookout, Errors Inbox, Change Tracking, and the AI-driven incident intelligence layer add a workflow surface on top of the raw telemetry. None of this is being criticized here. The functionality is real, the engineering is mature, and the integrations are extensive. The architectural property this article scrutinizes is orthogonal to functional capability: it concerns where governance authority over the telemetry namespace structurally resides.

The architectural gap

A New Relic agent embedded in a customer application emits telemetry events that are shipped over the wire to New Relic's collectors. Once received, those events are written into NRDB, indexed against the entity graph, and evaluated against alert conditions, anomaly detectors, and dashboard queries that live in New Relic's control plane. The customer authors NRQL queries, defines alert policies, and configures entity tagging through the New Relic UI or NerdGraph API. Every one of those artifacts is stored server-side, executed server-side, and governed server-side. The telemetry record itself is inert: a metric value, a span, or a log line carries no embedded reference to which alert governs it, which dashboard depends on it, or which retention policy applies.

The consequence is that the rules and the data are decoupled in a particular direction. Telemetry travels from the edge to the center. Authority travels from the center outward only as evaluation results — alert firings, dashboard renderings, anomaly flags. If the customer wants to know why a metric was tagged a particular way, why a service entity was synthesized into a specific cluster, or why an alert fired against one host but not another, that information lives in New Relic's rule engine, not in the metric. Replaying the telemetry against a different rule set requires either re-querying in NRQL or exporting raw data and rebuilding the rule logic externally, neither of which preserves the original governance lineage.

This is the structural shape of every centralized observability vendor. Splunk operates the same way around its search head. Datadog operates the same way around its query API. The shape is not a New Relic defect; it is the dominant architecture of the category. But the shape has a cost: namespace authority over a customer's own telemetry — how entities are named, how attributes are normalized, how relationships are synthesized, how retention is bounded — is exercised by the vendor's centrally hosted rule engine, not by the infrastructure team operating the systems being monitored.

What an adaptive-indexing primitive provides

An adaptive-indexing primitive operates on a different premise. Instead of treating the telemetry namespace as a single global structure governed by a central rule engine, it treats the namespace as a set of locally governed scopes, each anchored by an explicit governance node held by the team responsible for that scope. An anchor for a payments service, for example, is held by the payments team. The schema, retention policy, attribute taxonomy, and entity synthesis rules for that scope are committed against that anchor with cryptographic lineage. When telemetry is emitted within the scope, it carries a reference to the governing anchor, and any downstream consumer — whether a query engine, an alerting layer, or a federated index — can verify that the telemetry was governed by the policy the anchor advertises.

Concretely, the primitive provides three things the centralized model does not. First, scoped governance: each namespace segment is governed by its operators, not by a single tenant-level rule store. Second, structural lineage: every change to the namespace — a new entity type, a renamed attribute, a tightened retention bound — is committed against the anchor and produces a verifiable history. Third, traveling rules: the policy reference travels with the telemetry record, so consumers downstream can evaluate the record against the same policy that governed its production, without round-tripping through a centralized rule engine. This is what is meant by “rules ship with the metric.”

Composition pathway with New Relic

Adaptive indexing is not a replacement for New Relic. NRDB's columnar store, NRQL's query expressiveness, and the Errors Inbox / Lookout workflow surface remain valuable, and most enterprises that have standardized on New Relic have done so for substantive reasons. The composition pathway is one in which the customer retains New Relic as a query and visualization plane while interposing an adaptive-indexing layer at the boundary where governance is exercised.

In practice this means the New Relic agent or OpenTelemetry exporter is configured to attach an anchor reference and a scope identifier to outgoing telemetry. Local anchors hold the namespace policy — entity definitions, attribute schemas, retention bounds — and commit changes with lineage. Telemetry that reaches NRDB carries those references as attributes, and NRQL queries can select on them. Alerts and dashboards built in New Relic continue to function; they simply now operate over a namespace whose authority is structurally external to the vendor. When the customer wants to migrate, federate with another observability backend, or audit historical governance decisions, the anchor lineage is the source of truth, not the New Relic configuration export.

Over time, this lets infrastructure teams govern their own telemetry namespace at the speed they evolve their systems — without coupling that governance velocity to New Relic's release cadence or pricing tier.

A second composition mode is available for organizations running multiple observability backends. It is increasingly common for an enterprise to send metrics to one vendor, traces to another, and logs to a third — or to run New Relic for application teams while operating Prometheus and Loki for platform teams. In a centralized model, each backend imposes its own namespace, and the customer reconciles them through dashboards or correlation IDs. In an adaptive-indexed model, the anchor lineage is the cross-backend identity layer: the same anchor reference appears in NRDB, in the Prometheus remote-write stream, and in Loki labels, and federation tools query against the anchor rather than against any single vendor's namespace. The customer's namespace becomes the durable artifact; the vendors become interchangeable consumers.

The migration story is also relevant. Observability vendor switches are notoriously painful precisely because the customer's namespace — the entity definitions, the dashboard library, the alert taxonomy — is captured in vendor-specific configuration. Moving from New Relic to Datadog, or vice versa, is therefore not a data-migration exercise but a namespace-rebuild exercise, and most enterprises avoid it for that reason even when commercial terms would otherwise warrant a switch. An anchored namespace inverts the dependency: the customer's namespace becomes the durable artifact, and the vendor configuration is a projection of it. A switch becomes a change of consumer, not a rebuild of authority. This is not a hypothetical benefit; it is the same property that made Kubernetes manifests portable across cloud providers and made Terraform state portable across IaaS vendors. Adaptive indexing brings the same property to the observability namespace.

A third mode, useful for regulated industries, is governance-required telemetry. Records bound to anchors carrying compliance policies (for example, segments declared as covering protected health information, payment card data, or export-controlled telemetry) are routed through validators that block exfiltration to backends not authorized for the scope. The validation is structural: the anchor's policy declares the authorized destinations, and the routing layer refuses to ship the record elsewhere. New Relic remains a permitted destination for scopes whose policy allows it; scopes whose policy excludes it are simply never shipped. This is the kind of guarantee that today is implemented through manual configuration discipline and audited after the fact; the primitive moves it into the wire format.

Commercial and licensing posture

Adaptive Query's adaptive-indexing primitive is offered under a dual-track model: a permissive open reference for the wire format and anchor protocol, and a commercial license for the production-grade anchor implementation, governance tooling, and federation services. New Relic customers do not need to renegotiate their New Relic contract to adopt the primitive; integration occurs at the agent or OpenTelemetry collector boundary and does not require changes to the New Relic data plane. The intellectual property covering the anchor governance model, the lineage commit protocol, and the scope-routing layer is held by Adaptive Query and is available for license to platform vendors who wish to embed the primitive directly. Inquiries on licensing terms, OEM arrangements, and governance-layer integrations are handled through the contact channel on this site.