Bifrost is a new high-volume OpenTelemetry data-loading path for Axiom's machine data platform, now in private preview. It brings Axiom's encoding, compression, batching and storage-layout intelligence closer to where telemetry is produced, and it's designed to cut the cost of loading telemetry by more than half at petabyte scale.
The conventional telemetry path asks a centralized ingest pipeline to reshape every byte: parsing, shaping, encoding and batching happen after the data arrives, inside the platform's managed, multi-tenant loading tier.
For the vast majority of workloads, including at substantial scale, that's the right design, and it's how Axiom's standard pipeline will keep working. At sustained multi-PB volume, though, that reshaping compute stops being an implementation detail and becomes a material part of what a team pays to send the data, irrespective of how competitive the platform's economics are. When loading cost becomes material, teams understandably sample, drop fields, aggregate or shorten retention, and the evidence their observability estate exists to preserve is exactly what gets whittled away.
If you're responsible for an OpenTelemetry estate measured in PBs per month, this likely isn't news to you. It's a systems and economics problem you already own.
What we learned scaling with frontier model labs
We've spent the last few years scaling Axiom alongside frontier model labs whose machine data grew into tens of PBs a month: Kubernetes logs, OpenTelemetry traces, inference systems, network and edge traffic, voice systems, internal developer infrastructure.
The lesson from those workloads wasn't "make the telemetry cheaper by compromising on the telemetry." The usual ways to cut loading cost all buy the discount with a trade:
sampling cuts the bill by cutting how much data you send,
parking telemetry in object storage cuts it by cutting how queryable the data is once it lands, and
custom-built pipelines cut it by trading the product experience for new infrastructure to manage.
At frontier scale, the shape of the data path itself should change without changing how much data teams send, how fast it's ready to query, or what they have to maintain. More of the preparatory work needs to happen near the source, before every byte has to be reshaped by a standard managed ingest pipeline.
Axiom has spent years building a proprietary storage format, compression and encoding techniques, batching and layout logic, a PB-scale event store, and a serverless query engine for machine data. Bifrost is the consequence of applying that system knowledge to the path into the platform.
That system knowledge shows up as measurable storage density. In a comparison across representative machine-data workloads, Axiom's production format produced the smallest output.
Workload | Axiom production | Vortex compact | Parquet Zstd 22 |
|---|---|---|---|
OpenTelemetry traces/spans · 2.29M rows | 65.20 MiB | 86.56 MiB · 33% larger | 93.18 MiB · 43% larger |
High-volume application logs · 2.16M rows | 61.06 MiB | 69.82 MiB · 14% larger | 65.92 MiB · 8% larger |
└ The test sample was representative of petabyte-scale AI workloads.
What Bifrost does
Bifrost sits in the OpenTelemetry egress path. It uses Axiom's knowledge of encoding, compression, batching and storage layout to prepare compact, well-shaped, query-ready columnar batches near the source, where telemetry from data centres and other concentrated source environments is produced. Those batches are streamed into object storage and are registered for Axiom's query engine.
This only works because Axiom queries object storage as its hot store. A block in the right format streams to S3, is validated and registered, and becomes queryable without a second processing stage. Most platforms treat object storage as a warm or cold tier, so externally prepared data still has to be processed before it can be queried. Axiom's architecture is what makes a path like Bifrost possible.
Note: A collector configured to create large batches and compress them before sending can substantially reduce bandwidth, but ingest compute is still required when the data arrives. Bifrost both reduces bandwidth and removes the need for that ingest compute.
Two things Bifrost is not:
It's not a different telemetry model. The proposition starts from OpenTelemetry, and Bifrost belongs at the egress and collector layer, not inside every application.
It's not a datastore you operate. Axiom remains the managed machine data platform, and after the data lands it lives in the same storage, retention and query world as data that arrived through the standard pipeline.
Bifrost is designed so teams can keep more OpenTelemetry data instead of sampling it away.
In concrete terms, Bifrost data-loading compute starts at $0.025/GB, compared with $0.06–$0.12/GB on Axiom's standard managed path, and falls to $0.015/GB at the highest-volume tier. Block registrations are billed separately at $0.0065 per 1,000 registrations.
Storage and query pricing are unchanged. What changes is the loading component (the compute required to shape data for storage) while storage and query remain with Axiom.
How to get access
Bifrost is currently in private preview for PB-scale OpenTelemetry workloads.
If observability economics at scale is a problem you own and you'd like to learn more about getting access, reach out to Neil, co-founder and CEO, at njp@axiom.co for more information.