// the find
m3db/m3
M3 monorepo - Distributed TSDB, Aggregator and Query Engine, Prometheus Sidecar, Graphite Compatible, Metrics Platform
M3 is a distributed time-series database that Uber built and open-sourced, meant for metrics volumes a single Prometheus can't hold. It bundles a storage node (M3DB), a coordinator that speaks PromQL and Prometheus remote read/write, a streaming aggregator for rollups and downsampling, and a Graphite-compatible path. It is for platform teams running metrics infrastructure, not for someone with one Prometheus server and a few hundred series.
- The coordinator accepts Prometheus remote write and serves remote read, so an existing Prometheus can be pointed at M3 without rewriting dashboards or queries. The scripts/development/m3_prom_remote_stack directory shows that wiring end to end.
- The aggregator is a separate process that rolls metrics up before they reach long-term storage. You can write downsampled data to a longer-retention namespace, which is an architectural choice rather than a bolt-on feature.
- scripts/docker-integration-tests covers replication, multi-cluster writes, query fanout, cold writes, and repair as separate topologies. Distributed storage bugs tend to appear in exactly those paths, and having them in-tree is a good sign.
- The repo was pushed four days before this snapshot, so it is clearly still maintained.
- Operational weight is high. A real cluster needs etcd for placement, separate dbnode and coordinator processes, optionally the aggregator, and namespaces with explicit retention and block sizes. The one-container quickstart hides most of that, and it pins quay.io/m3db/m3dbnode:v1.0.0, so check it against the current release before copying it.
- The in-repo documentation is thin. The README covers a Docker quickstart and then sends you to m3db.io for everything else. The real deployment shape lives in config/, kube/, and the jsonnet files, and config questions often mean reading Go source.
- Building from source is slower and more fragile than a typical Go repo. It depends on a git submodule (.ci), Docker-based generators for Thrift and protobuf (thriftgen.Dockerfile, proto-gen.sh), and a Makefile that wraps all of it.
- One repo holds storage, aggregation, the PromQL coordinator, Graphite, Kubernetes manifests, Grafana dashboards, and benchmark tooling. The README doesn't say which parts are the supported path, so you have to work that out yourself before adopting it.