VictoriaMetrics

What is VictoriaMetrics?

VictoriaMetrics is a time-series database designed to be cheaper and faster than Prometheus at scale. It speaks the Prometheus query language and remote-write protocol, so it can sit behind an existing setup as a drop-in long-term store.

Best for

Long-term metric storage on modest hardware

Why choose VictoriaMetrics

VictoriaMetrics solves the two problems that eventually hit every Prometheus deployment: storage growth and query speed on long ranges. It speaks PromQL and the remote-write protocol, so it slots behind an existing Prometheus setup as a long-term store without changing your exporters or your dashboards. Its compression is significantly better than the default Prometheus engine, which means months of retention fit in the space weeks used to occupy, and it is comfortable on modest hardware — a small VPS handles ingestion rates that would strain a larger Prometheus. Single-node mode is genuinely one binary, which makes the entry cost unusually low for a time-series database.

Replaces

• Prometheus
• InfluxDB
• Thanos

Key features

• PromQL-compatible query language
• Accepts Prometheus remote write
• Better compression and lower memory use than vanilla Prometheus
• Single-node or clustered deployment

What to watch out for

The single-node and cluster versions are different products with different tradeoffs. Single-node is simple and fast but does not scale horizontally or survive a node loss on its own; the cluster version adds components and real operational complexity. PromQL compatibility is close but not identical, and edge queries occasionally behave differently than they would in Prometheus. Alerting is not its job — you still need vmalert or a separate Prometheus to evaluate rules. Documentation is dense and assumes familiarity with the Prometheus ecosystem, so the learning curve is mostly the ecosystem rather than this product.

How to deploy

• Single binary or Docker
• Point Prometheus remote_write at it
• Add as a Grafana data source

Getting started

Begin with single-node and a persistent volume, pointing your existing Prometheus at it via remote_write and confirming retention and query behavior before removing any local storage. Keep a small Prometheus (or vmalert) for rule evaluation rather than assuming this replaces alerting. Verify that the queries on your most-used dashboards return the same shape of data as before — this is where subtle incompatibilities surface. Set retention and storage limits explicitly. Only consider the cluster version once a single node is demonstrably the bottleneck, and treat that migration as a project rather than a config change.

Typical setup

It usually starts as one binary with a persistent volume receiving remote_write from an existing Prometheus, which keeps scraping and rule evaluation where they already work. Retention and storage limits are configured up front, and the dashboards that matter are checked for identical results before local Prometheus storage is reduced. Where alerting must keep working, vmalert or a small Prometheus remains in place rather than being removed. Ingestion and query rates are monitored, and the data directory is part of the backup routine, because a time-series store restored from nothing means losing all history.

Who should look elsewhere

Stay with plain Prometheus if your retention needs are weeks and your data volume is small — the extra component buys you nothing yet. Avoid the cluster edition unless you genuinely need horizontal scale, because it reintroduces the operational burden you were trying to escape. And if you want a time-series database with built-in alerting and dashboards rather than a storage engine that plugs into someone else's, this is not that product.

Project health

• GitHub stars: 17,800
• Last code push: 2026-10-02
• Open issues: 785
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.