PATTERN Cited by 1 source
Decouple reads from writes at storage layer¶
Decouple reads from writes at storage layer is the architectural move of making the read tier and the write tier independent of each other by inserting a shared object-storage substrate between them. Each tier scales, fails, and is upgraded on its own schedule.
The pattern¶
clients
|
v
+---------+ +---------+
| writer | | reader |
| tier | | tier |
+----+----+ +----+----+
| ^
v |
+--------+ +--------+
| object |<--------| object |
| store | | store |
+--------+ +--------+
(writes) (reads)
- Writer tier: stateless batch-buffers. Accept incoming writes, batch into blocks, PUT blocks to object storage, acknowledge. No inter-writer replication; durability is delegated to the object store's own N-way replication.
- Reader tier: stateless query nodes. GET blocks from object storage (or from a hot-data cache in front of it), run the query, return results.
- Object storage: the single source of truth. All durability, all authoritative state.
Why it matters¶
Retires two Cortex-era problems simultaneously:
- Write-path replication cost. No more N× compute/network/memory on ingest for durability.
- Coupled read/write scaling. A read burst (bursty query pattern) no longer steals capacity from writes; a write spike no longer degrades queries. Each tier sized for its own load.
Per Grafana Labs' Pyroscope 2.0 launch post:
"Mimir recently redesigned its architecture to eliminate write-path replication, decouple reads from writes, and make object storage the single source of truth. Pyroscope 2.0 applies similar architectural principles."
(Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)
Instances of the pattern¶
- Grafana Mimir — the canonical instance; metrics DB. Mimir's rearchitecture blog post (linked from the Pyroscope 2.0 post) has the quantitative benchmarks.
- Pyroscope 2.0 — the second instance; continuous-profiling DB. Adapted for profiling-specific traits (large payloads, symbolic information, bursty queries).
- Loki — logs DB; started from Cortex like Mimir and Pyroscope, on the same trajectory. Grafana Cloud Logs features launch managed-first while Loki converges.
See patterns/observability-db-rearchitecture-cortex-to-object-store for the unifying framing across all three.
Tradeoffs¶
- Write ACK latency gains an object-store PUT. Batching and async ACK after batch-commit mitigates this, but p99 ingest latency does shift.
- Hot-recent-read path needs its own design. The ingester tier no longer holds hot data for reads. Options: a recent-data cache in front of object storage, or direct object-storage reads with aggressive range caching.
- Operational shape changes. Instead of "add another ingester," the runbook becomes "add a writer" or "add a reader" — you need to know which is the bottleneck.