Aggregate across millions of tag combinations.
Dedicated metrics datastore. High-cardinality tags as a design principle, not a cost-control penalty. Optimized storage and fast aggregations across millions of unique tag combinations.
PLATFORM / METRICS
Metrics on the same dial as your logs and traces.
Capture every dimension your systems actually emit. Axiom's metrics datastore is purpose-built for high-cardinality time-series and queried in MPL right next to your logs, events, and traces.
ENGINEERING ON METRICSDB
The design decisions behind MetricsDB, documented.
Metrics launch
High-cardinality metrics, unified with logs and traces, fully queryable by AI agents.
Dynamic subrings
Consistent hashing without the tradeoff. How MetricsDB rebalances series without reshuffling the world.
Sortable interface
Column-aware sort, 2× to 26× faster across query types in the MetricsDB explorer.
ARCHITECTURE / METRICSDB
A metrics datastore built for high cardinality.
The legacy metrics model assumed a small number of tags per series. Modern systems blow through that assumption: AI workloads add prompt IDs, model versions, and per-request token counts; microservices add per-request trace IDs and per-tenant labels. Traditional systems respond by charging per dimension or by silently dropping high-cardinality tags. Neither preserves what engineers actually need to see during an incident.
TECHNICAL DEEP DIVES
Every dimension, on one engine.
Query time-series in a language built for it.
Metrics query language, on the same usage-based dial as APL. Engineered for aggregation and time-series; renders in the Axiom Console alongside APL queries on logs and traces.
Ship metrics through the standard OTel Collector.
Standard OTel collector, no proprietary agent. Histograms, counters, gauges, and summaries map one to one with OpenTelemetry semantics.
Tag per request, per tenant, per model.
Store metrics with high-cardinality dimensional tags without performance degradation or per-dimension cost. AI workloads, multi-tenant labels, per-request trace IDs all fit.
Ingest from the platforms you already run.
Vercel, Cloudflare, AWS (CloudWatch metrics), Kubernetes, and any system that emits OTel metrics.
Let your AI agents query metrics, too.
The native MCP server includes a metrics skill so AI agents can query metrics in MPL the same way they query APL.
“No BS, clarity in the docs, in the UI and API, very good support for Otel traces, logs and metrics.”
— Getlarge.eu
FAQ
What engineers ask first.
ARCHITECTURE AND QUERY
None on Axiom Cloud for typical workloads. MetricsDB is designed around high-cardinality as a first-class design principle, not an exception. Soft limits exist for sanity (datasets, dimensions per metric) and are liftable on request.
Metrics aggregation is a different workload from log-style filtering. MPL is purpose-built for time-series; APL is purpose-built for sequential log / event / trace queries. Keeping the boundary explicit keeps both languages clean.
INGEST
Yes. Standard OTel collector emits directly; histograms, counters, gauges, and summaries map one to one with OpenTelemetry semantics.
Yes. Use the OpenTelemetry SDK to emit any custom metric. Counters, gauges, histograms, summaries all supported.
MIGRATION AND PRICING
Yes. Most teams stand up the OTel collector first, run both stacks in parallel for a workload, then cut over at the next renewal seam. No per-dimension surcharge, no Standard Indexing SKU.
Same usage-based dial as the rest of Axiom. Sub-linear at higher tiers, included on Axiom Cloud up to the Always Free allowance.
DASHBOARDS AND AI
Yes. The Axiom Console mixes MPL and APL panels in the same view. Pivot from a metrics anomaly to the surrounding spans without a join.
Through the native MCP server with the metrics skill, in MPL. The same primitives you use in the Axiom Console.
High-cardinality metrics, on a bill you can predict.
Petabyte-scale ingest. Pricing you can predict.