The Prometheus shift and the search for scalable storage

The transition from Graphite to Prometheus was a major shift in how engineers manage observability. In 2015, the Prometheus tagged data model provided the flexibility needed for highly dynamic environments. This model allows users to group and filter metrics based on labels rather than a rigid hierarchy. As Kubernetes grew in popularity, Prometheus became the standard for scraping targets via its pull-based mechanism. Many open source projects now provide exporters to make this process even more efficient for modern workloads. However, scalability remains the primary weakness for teams managing massive amounts of high cardinality telemetry data. Modern systems emit huge amounts of multidimensional data from hardware, the operating system, Docker, and Kubernetes. This complexity arises because teams must monitor multiple layers: infrastructure metrics, container runtime and Kubernetes metrics, and application and business performance metrics. The surge in the number of discrete components you need to monitor in a microservices architecture creates a massive volume of telemetry. When companies like Uber reported 4,000 microservices in 2014, they faced immense challenges because their monitoring systems could not scale with their growing infrastructure. These systems require a clustered solution that can hold historical data long term without sacrificing data granularity through aggressive downsampling. This requirement for long-term storage drives the decision between Thanos and VictoriaMetrics. In 2020, Prometheus held 32,000 stars on GitHub, while Graphite fell to 78th place on the DB-Engine rankings. Traditional monitoring tools like StatsD used a push model that required configuring every component with a destination, but Prometheus avoids this through automated service discovery.

Thanos and VictoriaMetrics provide different paths for long-term metric retention. Thanos uses a sidecar model that sits alongside Prometheus to upload data to object storage like Amazon S3. This allows for global queries across multiple Prometheus instances, but the Thanos sidecar requires you to disable data compaction in Prometheus. This requirement increases RAM usage and can negatively affect Prometheus performance. Thanos includes several components like the Querier, Store, Compactor, and Rule nodes to manage this process. The Compactor acts as a singleton process that merges blocks and handles downsampling. The Store node acts as a gateway to block data that is stored in an object storage bucket and translates requests into object storage requests. VictoriaMetrics provides a simpler architecture because it is written from scratch in Go. It can replace Prometheus or act as a remote storage target via the remote write protocol. VictoriaMetrics uses block storage such as Amazon EBS or local HDDs, whereas Thanos relies on object storage. While object storage is cheaper per gigabyte, block storage provides much higher throughput and lower latency for your queries. Thanos can lose up to 2 hours of recent data if it is not synced to object storage, while VictoriaMetrics may lose only a few seconds of recent data that has not synced to persistent storage.

The choice between these systems often comes down to the operational tax your team can afford. VictoriaMetrics is a single binary that requires less CPU, RAM, and disk IO than Prometheus or Thanos. I would skip the Thanos sidecar model if you want to avoid managing many moving parts and complex network dependencies. VictoriaMetrics v1.139.x, released in March 2026, is built for efficiency and can handle billions of active time series in its cluster version. For teams sending data across cloud regions, the VictoriaMetrics remote write protocol provides better efficiency because it uses zstd compression instead of Snappy, which can reduce monthly network transfer costs from $10,000 to $2,500 when you transfer one million samples per second. vmagent, the data scraper for VictoriaMetrics, requires less CPU and RAM than the Prometheus agent when scraping an enormous number of targets. It also provides independent disk-backed buffers for each configured remote storage so that slow storage does not prevent data delivery to healthy storage. You should evaluate your own telemetry profile before making a final decision. When you evaluate the total cost of ownership, you must consider that VictoriaMetrics requires much less RAM and disk space than competing solutions that rely on the heavy overhead of object storage and sidecar components. VictoriaMetrics can handle up to 100 million active time series in its single-node version. Does the cost-savings of object storage justify the increased latency in your specific environment?