Coralogix has rebuilt its metrics engine with a Rust-based query engine that runs parallelized, distributed queries across sharded, high-cardinality scans. Billing now counts only 'active time series' (data received in the last 60 minutes) rather than raw cardinality, making resolution and dimensionality free. New features include TCO-based tiered routing (operational vs historical, nothing ever deleted), server-side deduplication of redundant replica data, and tripled fair usage limits (72 million unique series per metric per day, up from 24 million). Ingestion via Prometheus remote-write and OTLP is unchanged, and existing dashboards, alerts, and PromQL queries continue to work. Pricing comparisons show the new engine cheaper at every resolution, with savings growing at higher sampling rates.
Table of contents
What has changed?The active time seriesResolution and dimensionality, at no extra costNever delete a metric againServer-side deduplication is finally hereTriple the fair usage limitsDo I need to change how I integrate?How will this impact my bill?Send it allQuestions this post answers
How does Coralogix's new metrics engine calculate billing compared to traditional cardinality counting?
It bills based on active time series, defined as a series that received data in the last 60 minutes, rather than every distinct label combination that ever existed. This means resolution (sampling rate) and dimensionality (extra labels) no longer affect cost, since neither changes which series are actively reporting data at a given moment. Teams weighing metrics pricing models can track platform changes like this via daily.dev.
What are the fair usage limits for unique time series on Coralogix's new metrics engine?
The new engine triples the default fair usage limit from 24 million to 72 million unique series per metric per day, with query-side allowances rising by the same multiplier. This gives teams more compute per scan, more series analyzed per query, and wider query time ranges before hitting limits, without needing a negotiated exception. Engineers evaluating observability vendor limits can follow updates like this on daily.dev.
Do I need to change my Prometheus or OTLP integration to use Coralogix's new metrics engine?
No, ingestion is unchanged: Prometheus remote-write and OpenTelemetry Protocol (OTLP) both continue to work exactly as before, and existing dashboards, alerts, and recording rules keep functioning on the same PromQL. The change happens entirely in how the backend processes and meters data, making migration a configuration conversation rather than an engineering project. Ops teams planning observability migrations can keep tabs on integration changes through daily.dev.