The hidden costs of Loki log migration

The cardinality trap

I see teams leave Splunk to escape costs of $1,800 to $2,500 per GB/day only to struggle with Loki’s architecture. Loki indexes metadata through labels instead of the full-text indexing Splunk uses for every keyword. This design minimizes storage. But high cardinality ruins performance. If you use labels like user_id, IP addresses, or session_id, you create thousands of streams. These streams force Loki to build a massive index and flush thousands of tiny chunks to the object store. You should move high-cardinality data to log content or use structured metadata instead.

Loki needs labels.

If you assign labels with unbounded values like request_id, trace_id, or customer_id, performance degrades. For example, combining status_code and action creates 15 unique streams, but adding an endpoint label triples this to 45. You should use static labels like environment, namespace, or service_name. Avoid labels like timestamp, which Loki already stores. Since Promtail reached end-of-life on March 2, 2026, you must use Grafana Alloy for these pipelines.

A multi-meter billing structure

I recommend checking the three-part billing model before you switch from Datadog. Datadog is a unified SaaS solution with over 700 built-in integrations. It allows users to ingest all logs and only index the data they need. For 3-day retention, Datadog costs $1.06 per million log events, while 30-day retention costs $2.50 per million log events. You also face a $0.25 per GB outbound fee for data leaving the platform. Grafana Cloud Pro starts at $19 per month. It uses a three-part billing model for logs, traces, and profiles. You pay $0.05 per GB to process, $0.40 per GB to write, and $0.10 per GB for monthly retention.

The bill grows fast. You must account for processing and writing costs, not just storage. The 50 GB free tier for logs and traces disappears quickly when you scale. High-volume metrics also add pressure, as $6.50 per 1,000 billable series applies to the 95th percentile of active series.

The migration reality

Migration requires a full architectural redesign. You cannot simply translate Splunk’s SPL into LogQL. This move demands a new label taxonomy to avoid query degradation. Engineers moving from Splunk must map imperative, table-oriented commands to the functional expressions of LogQL which uses log stream selectors and pipeline stages to process telemetry data after selecting the specific, targeted, and unique log stream.

The complexity is high. You should plan your labels carefully. Mitigating high cardinality prevents failures. Will your budget survive the scaling?

Splunk utilizes Time Series Index files that create a map of every keyword, often resulting in an index that exceeds the size of the raw data. Loki uses a different approach, storing compressed chunks in object storage. You must redesign how you categorize data at ingestion. In Splunk, fields are extracted at search time using configuration files like props.conf or transforms.conf. In the Grafana stack, these search-time extractions become LogQL parsers like | json, | logfmt, or | pattern. The replacement of Splunk’s transaction command is particularly difficult. Loki avoids centralized, state-heavy operations, so you must use TraceQL or Prometheus recording rules to replicate those workflows. You also face labor costs. For every field extraction you move into Grafana Alloy pipeline stages, I estimate an additional 50 hours of engineering effort. You must use the unwrap function in LogQL to perform math on numerical labels. You must also use parsers like | json, | logfmt, or | pattern to extract data from the log stream.