New Relic vs. Axiom: turn an order search into an investigation

Support hands an engineer an order ID: payment kept the customer waiting. A log search finds a timeout, followed by a call from payments to inventory. The question changes from “Where is the record?” to “Where was time spent, and how many other requests were affected?” This is where event search meets application performance analysis.

New Relic can start that investigation from an APM service and extend it through NRQL. Axiom can start from an event dataset and follow correlations into traces and metrics. Axiom now has a dedicated metrics store and multi-signal navigation, so describing it simply as inexpensive logging misses part of the current product. This comparison covers hosted offerings using official sources checked on October 21, 2026; collection SDKs are not self-hostable analysis backends.

Make the queries answer the same question

Suppose identical application logs reach both systems and preserve a string field called order_id. New Relic can filter the Log data type with NRQL. Axiom can filter, project, and sort an EventDB dataset using APL. Field types and time windows must align before the results become comparable. NRQL reference, APL introduction

These examples illustrate filtering equivalent logs, not equivalence between the platforms' entire data models. Replace the dataset and fields with those actually ingested. The Axiom filter uses event time in _time.

SELECT * FROM Log
WHERE order_id = 'order-1042'
SINCE 1 hour ago LIMIT 100

['checkout-logs']
| where _time > ago(1h)
| where order_id == 'order-1042'
| project _time, message, order_id
| sort by _time asc
| take 100

Returning 100 records does not prove that only 100 events occurred. Result limits, time boundaries, upstream filtering, and duplicate delivery can affect the view. Use a separate aggregation for counts, and establish whether it counts log lines or requests. A single request can emit many records regardless of how similar the query syntax appears.

Continue from the record into the request

New Relic's APM logs-in-context feature connects records with application entities, traces, and spans. The agent can decorate and forward logs, or teams can preserve an existing forwarding pipeline. The useful test is whether the particular timeout record leads back to its invocation, rather than merely displaying nearby logs on a service page. Logs in context

Axiom's current correlation groups connect up to three datasets: OTel logs, trace spans, and MetricsDB metrics. Logs need context such as trace_id and span_id. With those datasets and correlations configured, an event can lead to its trace and related signals. This is a concrete investigative workflow, not just a common search box for unrelated JSON. Correlations

Axiom's trace model includes parent-child spans, durations, and attributes. An order ID is still not a trace ID. Retries, asynchronous callbacks, or broken propagation can distribute one order across multiple traces. Preserve both business and request identifiers instead of expecting the backend to infer causality that was never recorded. Trace structure

New Relic also maps OTel data into services and transactions. Some APM segment information comes from spans, so sampling affects the available detail. Compare application workflows with matching instrumentation and sampling, then follow the same request across service boundaries. OpenTelemetry APM UI

Metrics are not just logs drawn as lines

Axiom distinguishes EventDB from MetricsDB. Logs, traces, and events use APL in EventDB. OTel metrics require a dedicated MetricsDB dataset and can use MPL, currently in Public Preview; APL cannot query those metrics. Counters and histograms carry aggregation and time semantics that a broad “unified querying” description should not obscure. Metrics datasets, APL scope

Similarly, sampled Transaction event counts in New Relic are not automatically full-population request metrics. Discrete events help inspect an order; measuring its wider impact requires a clearly defined metric or event population. An error-rate chart calculated from sampled spans cannot be compared directly with one calculated from log records. New Relic data types

Query flexibility matters when teams can express these distinctions reliably. Moving existing NRQL dashboards or alerts to APL and MPL requires checking windows, missing fields, and aggregation semantics. A small fixture of known events and expected results is more useful than comparing screenshots after replacing query keywords.

Queries also consume budget

Axiom Cloud currently lists a $25 monthly platform fee plus usage, including allowances of 1 TB of monthly data-loading compute, 100 GB-hours of query compute, and 100 GB of storage. Additional usage is metered separately. Storage uses compressed capacity, while governance features such as SSO and RBAC have separate add-ons. The claim that Axiom charges only for ingestion and offers unlimited free queries is incorrect for this model. Current Axiom pricing

Query GB-hours represent execution duration multiplied by allocated memory, not simply gigabytes scanned. UI queries, API calls, monitors, and dashboard refreshes create query work. A dashboard repeatedly refreshing a broad historical window can keep consuming compute. Estimate from observed query costs as well as daily ingestion. Understanding query usage

New Relic documents Data + User and Data + Core Compute, with the latter still in Preview and available through an account representative; Advanced Compute is another category. Its ingested-data meter reflects data stored after platform trimming and transformation rather than raw bytes transmitted. Identify the agreement before estimating data, users, retention, and compute. New Relic billing

Historical investigations also depend on retention. New Relic applies effective settings by data type and account. Configurable retention in Axiom does not mean unlimited free storage. If an order's logs remain but its spans have expired, correlation cannot restore the missing side. New Relic retention

Design location and access together

Axiom currently documents AWS US East 1 and EU Central 1 edges. Ordinary event ingestion, storage, query execution, and result delivery use the selected edge, while account-management operations use centralized US infrastructure. The Axiom-hosted remote MCP server is another exception: query results pass through US infrastructure when accessed through it. A dataset's edge cannot be changed after creation, and additional edges involve an add-on. Choosing an EU edge therefore does not place every account operation in the EU or turn the service into a self-hosted deployment. Edge deployments

Prioritize Axiom when ongoing investigation of structured events is central and the team is prepared to maintain datasets, fields, and the required signal correlations. New Relic may offer greater continuity when existing APM views, cross-entity investigations, and NRQL assets already organize daily operations. Choose using a complete workflow and measured consumption; “object storage” and “full stack” are not performance or cost conclusions.

Preserve the order context in Guance

When assessing Guance, use the same order and trace to validate log correlation. Align log fields, trace identifiers, and service naming before judging the investigation experience. Useful business context remains worth preserving when the backend changes.