M3DB

Definition

M3DB is an open-source, distributed time-series database originally developed at Uber to store and query metrics at very large scale across a global infrastructure footprint. It is designed as one component of the broader M3 metrics platform, providing durable, horizontally scalable storage with built-in replication and multi-region support for high-cardinality operational monitoring data, and it commonly serves as a long-term remote storage backend behind Prometheus deployments that need retention beyond a single node.

Overview

Operating a service at the scale of a company like Uber means generating metrics volumes that outgrow single-node or lightly clustered time-series databases, particularly when many services emit high-cardinality tags such as per-request identifiers or per-customer dimensions. M3DB was built internally to handle that volume and cardinality reliably across multiple regions before being open-sourced as part of the wider M3 platform. Mechanically, M3DB shards time-series data across a cluster of storage nodes using consistent hashing, replicates each shard for durability, and stores data in an efficient encoded format on disk designed for compression and fast range scans by time window. It exposes both a native storage API and compatibility layers, including a Prometheus remote storage endpoint, so existing Prometheus-based monitoring stacks can use M3DB as a scalable, long-term storage backend instead of Prometheus's local, single-node storage. Among time-series systems, M3DB's distinguishing feature is native support for multi-region replication and very high write throughput at the storage layer, which is more built-in than what standalone engines like InfluxDB or OpenTSDB provide out of the box; OpenTSDB achieves scale by delegating storage to HBase rather than implementing distributed storage itself, whereas M3DB was purpose-built for this from the start. The trade-off is that M3DB is a more complex system to operate, generally justified only at a scale where single-node or lightly distributed alternatives clearly break down. In practice, organizations adopt M3DB as a long-term, horizontally scalable storage backend behind Prometheus, retaining Prometheus's query language and alerting while gaining durability and retention beyond what a single Prometheus instance can hold. It is most common in companies operating large microservice fleets across multiple data centers or cloud regions. The main limitation is operational overhead: running an M3DB cluster well requires managing multiple coordinated components (storage nodes, coordinators, and often etcd for cluster metadata) and understanding sharding and replication behavior, which is considerably more involved than deploying a single-node time-series database. Teams without Uber-scale metrics volume are usually better served by a simpler managed or standalone alternative. Choosing M3DB is therefore as much an organizational decision as a technical one: it pays off when a platform team can dedicate ongoing attention to cluster health, but it adds unnecessary operational surface area for a team that only needs metrics retention for a handful of services. Evaluating M3DB fairly means testing its coordinator and storage-node behavior under realistic write volume and node-failure scenarios beforehand, since a cluster that looks healthy under light load can behave very differently once it faces the sustained ingestion rate a large fleet of services actually produces.

Key Features

• Distributed, sharded storage with consistent hashing across nodes
• Built-in replication for durability across multiple regions
• Prometheus remote storage compatibility for long-term metric retention
• Encoded, compressed on-disk format optimized for time-range scans
• Designed to handle very high write throughput and cardinality
• Originated at Uber and released as open source
• Coordinator and storage node architecture for cluster management

Use Cases

Alternatives

Frequently Asked Questions

Related in Database