VictoriaMetrics vs Thanos

The data-loss window is set by how long samples sit in a place that is not yet durable in the long-term store. The VictoriaMetrics FAQ, which is the vendor's own comparison, says Thanos can lose up to 2 hours of recent data that has not been uploaded to object storage, against a few seconds for VictoriaMetrics. These are vendor claims, so treat them as hypotheses to test. The Thanos window follows from block shape: the sidecar uploads TSDB blocks as Prometheus produces them every 2 hours, and Thanos Receive uploads every 2 hours by default. Until a block is uploaded, its samples exist only on the local disk of the Prometheus or Receive instance that wrote them.

Prometheus local retention determines what a fallback store has to cover. Prometheus keeps data for 15 days by default, configurable by time or size, and its storage docs state that local storage is not clustered or replicated. Blocks already uploaded to the bucket survive a server loss, but anything still on that disk within the retention window does not. With a Thanos sidecar, local compaction must be disabled by setting min-block-duration and max-block-duration to equal values, because the sidecar docs warn that otherwise uploaded data can be corrupted. Decide whether the 15-day local window is your recovery horizon or only a cache, and size the upload interval against that decision.

Test the window in your own environment before relying on either number. Run a controlled outage: write a known synthetic series at a steady rate, then stop the Prometheus process, sidecar or Receive pod, or the VictoriaMetrics node while the scrape loop continues. After recovery, count the missing samples. Repeat the outage at different points in the block cycle, since a 2-hour window will show different losses depending on where the cut falls. Ask each vendor how remote write retries and buffers during a receiver outage, because that is a separate loss path. Record the results for each design and keep the test script under change control.

The main cost difference is where the bytes sit. With VictoriaMetrics, you pay for block storage and the compute that ingests and queries it. With Thanos, you pay for object storage plus the Prometheus servers that still need persistent disks, because the sidecar sits beside each one and the local TSDB remains part of the design. Ask the vendor or your own storage team to price both paths with the same series count and retention, since the storage class, replication and request charges on your platform decide which line is larger. Thanos also runs several components (Query, Store, Compact, and Receive or Sidecar), each with its own compute and monitoring footprint, so the infrastructure line grows with component count, not only with data volume.

Recurring costs are the ones that compound. Storage grows with active series and retention, so series cardinality is the first driver to measure: a single label that multiplies series count raises disk or bucket spend on either design. Downsampling reduces long-range storage on Thanos through its compactor, which the Thanos compactor docs describe as downsampling raw data older than 40 hours to 5-minute resolution and 5-minute data older than 10 days to 1-hour resolution. VictoriaMetrics Enterprise lists downsampling and multiple retentions among its features, so confirm whether your retention targets need that tier. Your people are the largest recurring line for most teams: on-call coverage, Prometheus and Thanos or VictoriaMetrics upgrades, and backup testing. Support subscriptions and any Enterprise license are optional costs that should appear as separate line items in a quote.

One-time costs are design, migration of existing rules and dashboards, and load testing against your real ingestion rate. Ask a partner to quote these as a fixed scope with named environments, retention targets per tier, and the upgrade cadence you expect to run, such as how often you will track VictoriaMetrics releases, which are published about every two weeks, or Thanos releases. Those four inputs turn an open-ended estimate into a comparable quote. If a quote omits Prometheus disk sizing, component count for high availability, or the rate of upgrades, ask for those assumptions in writing before comparing totals.

A VictoriaMetrics rollout starts with three decisions that are hard to reverse: how much block storage the instance needs, whether single-node or cluster fits the expected series count, and how long data is kept. Each Prometheus server, or a central collector, sends samples through the standard remote write API, so the Prometheus side is mostly configuration: a remote_write block pointing at the ingestion endpoint, plus relabeling where series need trimming. Confirm the sizing inputs with the vendor and in your own environment (active series, sample rate, retention) before choosing a topology, and decide early whether features such as downsampling, multiple retentions or backup automation are needed, since the VictoriaMetrics README places those in its Enterprise tier. Those choices then drive the license and support conversation.

A Thanos implementation has more moving parts. A sidecar must be deployed next to every Prometheus instance, which means a rollout across each server, not one central change. Because the sidecar uploads TSDB blocks as they are produced, the Prometheus min_block_duration and max_block_duration settings must be equal to disable local compaction; the Thanos sidecar docs warn that otherwise uploaded data can be corrupted, so this check belongs in the change plan for every server. The team also has to configure the object storage bucket, place the Thanos compactor as the single instance for that bucket, and deploy Query and Query Frontend components for users. Receive is the alternative path for teams that prefer remote write, and it adds its own tenant and upload configuration.

Projects usually run long in four places. First, retention and downsampling policy: Thanos compaction downsamples raw data after 40 hours and again after 10 days, so the retention targets agreed with the business must be settled before the bucket is populated. Second, cardinality surprises, which surface only after real traffic reaches the new store and can change sizing for either platform. Third, object storage permissions, where bucket policies, IAM roles and network paths for every Thanos component are often corrected during testing. Fourth, alert rule validation, because recording and alerting rules must be re-tested against the new query engine, and MetricsQL and PromQL differences should be checked query by query. Scope and timelines for any DeployOpen engagement are agreed in writing before work starts.