Prometheus is for smaller problems.  You have to manage your own sharding with prometheus, so it doesn&#x27;t work for handling large volumes of data unless you are willing to do complex automation for a large number of disparate replication topologies.  This works fine at Soundcloud, where it came from, because the teams there like keeping their monitoring systems isolated from each other because they don&#x27;t trust each other.<p>For problems where you require a single source of truth for high volumes of data, you can&#x27;t really justify that kind of effort for the data management when distributed databases have been created to solve this problem.<p>Prometheus is nice and featureful, but it makes me laugh when the proponents (usually [ex-]soundcloud folks) brag about how scalable it is.<p>Side note: they love to say that because it&#x27;s pull based, that magically makes it more scalable.  This is a crock of shit.  Push vs Pull doesn&#x27;t get you out of capacity planning, and from this perspective they are identical in terms of throughput requirements.  Pull means you need a single source to know about a ton of endpoints.  Push means you need a ton of sources to know about a single endpoint.  Which one is simpler to operate?  They say it&#x27;s more scalable because when they failed to properly do capacity planning, it hid their dropped data more effectively and their dashboards kept running, oblivious to the degredation.