Grafana Loki sizing

In short

• Object storage ≈ daily ingest × stored ÷ received × retention days, one copy, then growth. Grafana publishes no compression ratio, so ObservKit uses a conservative planning assumption of 1.0× (editable). Grafana does not recommend that value: measure your own ratio for production sizing.
• The replication factor (default 3) multiplies what ingesters receive, not what lands in the bucket.
• The WAL is local disk on ingesters. It scales with intake rate, not with retention.
• Compute comes from Grafana’s published reference profiles per ingestion tier. It is not derived from your data volume.
• Reference scenario 250 GB/day for 90 days with a 25% growth buffer is 28.1 TB of object storage at the conservative 1.0× planning assumption.

Where data lives

Distributors receive logs and write each stream to replication factor ingesters. Ingesters hold recent data in memory, record it in a write-ahead log on local disk, and flush chunks and index to object storage. Queriers read recent data from ingesters and everything else from the bucket, through caches and the index gateway. That gives three capacity types that should never be added together: object storage (TB), ingester disks (GB) and compute (CPU and memory).

Object storage

Chunks are compressed, but Loki’s documentation gives no ratio, because it depends on how repetitive your lines are and on label cardinality. Measure it: divide loki_ingester_chunk_stored_bytes_total by loki_distributor_bytes_received_total over a representative period, and replace the default factor with the result. Object storage scales linearly with the factor, so any measured ratio replaces the 1.0× assumption directly.

Reference scenario The same 250 GB/day for 90 days at a hypothetical stored ÷ received factor of 0.25 gives 7.03 TB, compared with 28.1 TB at 1.0. Open this scenario

Ingester WAL

Grafana publishes a single WAL data point: an ingester with about 5,000 series receiving about 5 MB/s, with WAL-only disk usage settling around 10–15 GB. ObservKit scales that one point linearly with total ingester intake (daily ingest × replication factor) and shows the result as an estimated cluster-wide WAL. It is a low-confidence rough planning estimate, not a required disk size: series count, checkpoint interval and flush behavior all change it. Ingesters stop accepting writes when the WAL filesystem passes 90% usage (the default disk-full threshold), so the calculator also shows what an even split per ingester would need to keep the high estimate under that threshold.

Reference scenario At 250 GB/day with RF 3 and 6 ingesters the WAL is 17.4–26 GB in total, about 4.82 GB of volume per ingester. With 3 ingesters the per-ingester volume rises to 9.65 GB. Open this scenario

Replication factor

With the default factor of 3, the distributor writes each stream to three ingesters, and a write succeeds once a quorum acknowledges it. When a chunk is flushed it is hashed by tenant, labels and contents, so identical replicas do not produce duplicate objects. Storage therefore does not triple. What triples is ingester intake, memory and WAL traffic. Entering RF × object storage is the most common sizing mistake.

Reference scenario At RF 1 the object storage stays 28.1 TB; only the WAL changes (8.68 GB high estimate versus 26 GB at RF 3). Open this scenario

Retention

Retention is off by default: logs are kept indefinitely until you enable the compactor’s retention (compactor.retention_enabled) and set limits_config.retention_period or per-stream rules. Changes are not retroactive. Deletion is delayed (retention_delete_delay, default 2 hours), and the minimum stream retention is 24 hours. Object-store lifecycle rules are only a safety net: Grafana advises keeping their expiry longer than the Loki retention plus the delete delay, and never expiring the index or compactor state.

Reference scenario At 7 days instead of 90, the same ingest needs 2.19 TB of object storage. Open this scenario

Deployment sizing

Grafana publishes reference CPU and memory requests per component for three ingestion tiers (under 3 TB/day, 3–30 TB/day and about 30 TB/day) and presents them as a rough guide. ObservKit shows the profile for the tier that matches your daily ingest, labelled as a Grafana reference profile; it does not scale or calculate it, because the published profiles are not a formula. Query workloads can require much more (Grafana warns unoptimized queries can need up to 10× the suggested resources), and cache sizing, label cardinality and retention behavior move real requirements too. Use the profile to start a load test, not to place an order.

Reference scenario At 250 GB/day the matching Grafana reference profile for distributed Loki <3 TB/day lists 38 CPU and 59 Gi of memory requests in total.

Worked example

Reference scenario EPS to Loki: 8,000 events/s at about 700 bytes is 483.84 GB/day (8,000 × 700 × 86,400). Kept 30 days with 25% growth at the conservative 1.0× factor, Loki needs 18.1 TB of object storage. Open this scenario

Common mistakes

• Multiplying object storage by the replication factor.
• Using the default stored ÷ received factor of 1.0 as if it were measured.
• Adding WAL volumes, object storage and compute into one total.
• Treating Grafana’s reference profile as a sizing formula for your workload.
• Relying on object-store lifecycle rules instead of Loki retention, or the reverse.

Limitations

The calculator does not model object-store request costs, query load, cache sizing, label cardinality, per-tenant limits, ruler or ingestion limits, or the Loki operator’s defaults. The WAL estimate is scaled from a single documented test. Retention is shown as days; the compactor’s actual delete timing is not simulated.

Sources

• Size the Loki cluster — Grafana Loki documentation: reference CPU and memory requests per ingestion tier.
• Write Ahead Log — Grafana Loki documentation: WAL behavior and the documented 10–15 GB data point.
• Loki components — Grafana Loki documentation: distributor replication, ingester, quorum and chunk flushing.
• Log retention — Grafana Loki documentation: compactor retention and lifecycle policy guidance.
• Observability (v2.9.x) — Grafana Loki documentation: metric names used to measure the stored ÷ received ratio.

Last reviewed: October 2026 · Grafana Loki Sizing Calculator · Capacity Planning · Methodology