VictoriaMetrics/VictoriaMetrics

VictoriaMetrics is worth a look if you already run Prometheus-compatible monitoring but are hitting storage, memory or query-cost limits. It is a single-binary time series database that accepts Prometheus-style data and adds its own query language.

The problem

A team collects metrics from Kubernetes, node exporters or application instrumentation into Prometheus. Over months the disk fills, memory grows with the number of active series, and dashboard queries over long ranges become slow or expensive. VictoriaMetrics changes the storage and query layer: existing scrapers and Grafana dashboards can keep working while points land in a backend built for long retention and high series churn. The visible result is a single query endpoint over data from multiple sources rather than separate short-retention Prometheus instances.

What's different

The design centres on a dependency-free binary configured mainly by command-line flags, with defaults described as already tuned. It supports both PromQL and MetricsQL, and the README positions it as a long-term store or drop-in replacement for Prometheus and Graphite in Grafana. Its global query view lets multiple Prometheus instances or other sources ingest into one place and be queried together, which is useful when you have per-cluster collectors. It also handles stream aggregation, so it can act as a StatsD alternative.

The performance claims come from the project's own benchmarks: roughly 10x less RAM than InfluxDB and up to 7x less than Prometheus, Thanos or Cortex on node-exporter metrics. Treat these as author benchmarks, not independent measurements. A core developer made a similar case in a 2023 Hacker News reply: better compression, lower memory use and faster heavy queries, while saying it can serve as a drop-in replacement "in most cases" (developer reply). That qualifier matters: query compatibility and operational behaviour need checking against your own dashboards and recording rules. Snapshots provide backup and restore mechanics, but they are an operational feature, not a guarantee about your retention or recovery plan.

Some capabilities sit behind the Enterprise edition: anomaly detection, automated backups, multiple retentions per dataset, downsampling for historical queries and long-term support release lines (enterprise features). For a team that needs different retention windows or downsampling to control storage, that changes the cost and licensing picture rather than being a minor add-on.

Who should try it

Good fit: an observability team running Prometheus-compatible collection at a scale where memory and disk are the binding constraints, especially with many short-lived series from Kubernetes or IoT telemetry. The single-binary setup and multi-source query view also suit teams consolidating several regional Prometheus servers.

Poor fit: someone who wants a small home-lab dashboard and has no existing Prometheus workflow, since the value here is in the storage and query backend rather than a turnkey UI. Also a poor fit if you need the Enterprise-only features and cannot take on a commercial arrangement; evaluate that before migrating.

Requirements and limitations

You need a Prometheus-compatible ingestion path, whether scraping, remote write or one of the other supported protocols, and Grafana or another query client. The binary itself has no external dependencies, but operating it means planning retention, disk capacity, backup snapshots and upgrades. Query compatibility is the main migration risk: the developer's "most cases" wording and the MetricsQL extension mean you should verify your dashboards and alerting rules rather than assuming identical results.

Enterprise-only features are the other boundary. Multiple retentions and downsampling are often exactly what large installations want for cost control, so check the enterprise feature list against your requirements. Ongoing upkeep includes monitoring the database itself and validating snapshots, especially before upgrades.

HotRepo's take

HotRepo recorded one daily-board appearance on 2026-10-27 at 17,913 stars, +6 that day; with a single dated observation, persistence of interest cannot be judged. A 2023 Hacker News thread drew 8 points and 3 comments, which indicates discussion volume only. The repo dates to 2018 and has a published release line (releases), so this is an established project rather than a new experiment. Before adopting, verify one thing: that your existing PromQL queries and Grafana panels return the results you expect against VictoriaMetrics, rather than relying on the drop-in claim alone.