VictoriaMetrics: Time Series Database and Monitoring

What VictoriaMetrics is

VictoriaMetrics is an open-source time series database and monitoring solution written in Go. It stores metrics, answers queries over them, and can scrape targets itself, so it fills the same role as Prometheus's storage layer and, in many setups, replaces it outright. The project describes itself as a fast, cost-effective and scalable way to monitor and manage time series data, and its README positions it as long-term storage for Prometheus or a drop-in replacement for Prometheus and Graphite as a Grafana data source.

The problem it addresses is what happens to monitoring as it grows. A single Prometheus server keeps data on local disk and is not built to be clustered, so teams that need long retention, a global view across many Prometheus instances, or high ingestion rates usually end up assembling something larger. VictoriaMetrics' answer is two-fold: a single-node binary that the project says scales vertically to millions of metrics, and a cluster version for when one machine is no longer enough. Both are open source under Apache-2.0; the README goes out of its way to say "we open-source both the single-node VictoriaMetrics and the cluster version."

The audience is platform and SRE teams running Prometheus-style monitoring, companies collecting metrics from Kubernetes, APM, IoT sensors or industrial telemetry, and anyone who wants to consolidate data arriving in several different metric protocols into one store queried through one language.

How it works

Single-node VictoriaMetrics is one process responsible for ingestion, storage and querying. It is distributed as a self-contained binary named victoria-metrics-prod with no external dependencies, configured entirely through command-line flags. The docs say the defaults are tuned well enough to start with no flags at all. Data lives under the directory given by -storageDataPath, split into per-month partitions, each made of data parts that background merges combine over time.

The cluster version splits that one process into three services that scale independently:

• vminsert accepts ingested data and spreads it across storage nodes using consistent hashing over the metric name and all its labels.
• vmstorage stores the raw data and returns it for a given time range and label filters.
• vmselect runs incoming queries by fetching the needed data from all configured storage nodes.

Storage nodes do not know about each other, do not communicate and do not share data. The docs call this a shared-nothing architecture and argue that it simplifies availability, maintenance and scaling. A minimal cluster is one of each component; the docs recommend many small vmstorage nodes (at least ten) over a few large ones, and suggest the single-node version for anyone who needs fewer. Requests are routed by path: /insert to port 8480 on vminsert and /select to port 8481 on vmselect, typically through a load balancer.

Around the database sits a family of companion tools documented in the same repository: vmagent for scraping and forwarding metrics, vmalert for Prometheus-compatible alerting and recording rules, vmalert-tool for validating rules, vmauth as an authorization proxy and load balancer, vmctl for migrating data between storage systems, and vmbackup and vmrestore for backups. vmgateway and vmbackupmanager are also documented, and the docs link VictoriaLogs as the sibling database for logs.

Key features

• PromQL and MetricsQL. Queries use MetricsQL, a PromQL-compatible language, so existing PromQL works while MetricsQL adds extensions the project says are more performant.
• Built-in Prometheus scraper. Single-node VictoriaMetrics can scrape Prometheus exporters such as node_exporter directly with a standard scrape_configs file passed via -promscrape.config, with no separate Prometheus server.
• Many ingestion protocols. The README lists Prometheus remote write and exposition format, InfluxDB line protocol over HTTP, TCP and UDP, Graphite plaintext with tags, OpenTSDB put messages and HTTP /api/put, JSON lines, arbitrary CSV, a native binary format, the DataDog agent and DogStatsD, the New Relic infrastructure agent, and OpenTelemetry metrics.
• Global query view. Multiple Prometheus instances or other sources can write into one VictoriaMetrics and be queried together.
• Stream aggregation. Aggregation at ingestion time, which the README says can serve as a StatsD alternative.
• Instant snapshots. Backup and restore rely on snapshots, with vmbackup and vmrestore for copying them elsewhere.
• Built-in UI. vmui at /vmui provides a query page and a metrics explorer for browsing everything collected.
• Multitenancy in the cluster. Tenants are identified by accountID or accountID:projectID in request URLs (and, from v1.143.0, HTTP headers), are created automatically on first write, and are spread evenly across storage nodes.
• Application-level replication. -replicationFactor=N on vminsert stores N copies of each sample on distinct storage nodes, so data stays queryable with up to N-1 nodes down.
• NFS-based storage. The README says VictoriaMetrics supports storing data on NFS-based storage such as Amazon EFS and Google Filestore.
• Relabeling and cardinality limiting. Metrics relabeling and a cardinality limiter help control what gets stored.

Performance claims

The README links a set of benchmarks, mostly written by the project's own engineers. Among them: handling millions of unique time series with "10x less RAM" than InfluxDB and up to "7x less RAM" than Prometheus, Thanos or Cortex; "20x" better ingestion performance than InfluxDB and TimescaleDB; up to "70x more data points" stored in limited space than TimescaleDB; and "7x less storage" than Prometheus, Thanos or Cortex. It also cites a Grammarly case study describing VictoriaMetrics as 10x more cost-effective than Graphite, and claims a single node can replace medium-sized clusters built on Thanos, M3DB, Cortex, InfluxDB or TimescaleDB.

Several of these benchmarks are years old and were run by the vendor against specific versions of the competitors. They are useful as an indication of the design goals (low memory per series, aggressive compression, good behaviour on high-latency and low-IOPS disks) but not as numbers to plan capacity on. The docs include a capacity planning section, and the honest approach is to replay a sample of real metrics into a test instance and measure.

Getting started

The quick-start guide's fastest path is the single binary. Create a working directory, download the release archive for the platform from GitHub, unpack it and run it with self-scraping enabled so there is data to look at immediately:

mkdir vm-quick-start && cd vm-quick-start

wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.155.0/victoria-metrics-linux-amd64-v1.155.0.tar.gz
tar xzf victoria-metrics-linux-amd64-v1.155.0.tar.gz

./victoria-metrics-prod -selfScrapeInterval=10s

VictoriaMetrics listens on port 8428. Opening http://localhost:8428/vmui shows the query UI, and self-scraped metrics become queryable within about 30 seconds. The guide suggests queries such as process_resident_memory_bytes and rate(process_cpu_seconds_total) to start.

To collect host metrics, run node_exporter, create a scrape.yaml with a scrape_configs entry pointing at localhost:9100, and restart with the scrape config flag:

./victoria-metrics-prod -selfScrapeInterval=10s -promscrape.config=scrape.yaml

Pushing data works with plain HTTP. This InfluxDB line protocol example from the guide writes one measurement, which then appears as room_temperature_value:

curl -d 'room_temperature,room=kitchen value=21.5' http://localhost:8428/write

For Docker, the docs pull a pinned image and mount a local data directory:

docker pull victoriametrics/victoria-metrics:v1.155.0
docker run -it --rm -v `pwd`/victoria-metrics-data:/victoria-metrics-data -p 8428:8428 \
 victoriametrics/victoria-metrics:v1.155.0 --selfScrapeInterval=5s -storageDataPath=victoria-metrics-data

A full cluster with storage, insert and select nodes, vmagent, vmalert, vmauth, Alertmanager and Grafana can be started from the repository's Docker environment:

git clone https://github.com/VictoriaMetrics/VictoriaMetrics && cd VictoriaMetrics
make docker-vm-cluster-up

For production on Linux, the quick-start guide walks through extracting the binary to /usr/local/bin, creating a dedicated victoriametrics system user and data directory, and writing a systemd unit, then enabling it:

sudo systemctl daemon-reload && sudo systemctl enable --now victoriametrics.service

Other installation routes listed in the docs include Helm charts, a Kubernetes operator, Ansible roles, a DigitalOcean marketplace app and building from source.

Use cases

• Long-term Prometheus storage. Keeping Prometheus for scraping and alerting while sending data to VictoriaMetrics via remote write for retention measured in months or years.
• Prometheus replacement. Using the single binary's built-in scraper plus vmalert in place of a Prometheus server, keeping Grafana dashboards and PromQL queries.
• Consolidating protocols. Accepting Graphite, InfluxDB, OpenTSDB, DataDog, New Relic and OpenTelemetry metrics into one store during or after a migration, then querying everything with MetricsQL.
• Multi-team or SaaS monitoring. Using cluster multitenancy to keep each team's or customer's metrics isolated under separate tenant ids behind an auth proxy.
• High-cardinality workloads. Kubernetes clusters with heavy pod churn, where the README says VictoriaMetrics is optimized for old series being replaced by new ones at a high rate.
• Migration from other TSDBs. Using vmctl to copy historical data from another storage system before switching ingestion over.

Retention, availability and operations

Retention is set with -retentionPeriod, which takes a number and a unit (hours, days, weeks, months or years) and defaults to one month. A bare number means months of 31 days. Because data is partitioned by month and partitions outside retention are deleted on the first day of a new month, the docs warn that maximum disk usage for a given retention is the retention period plus one month. Extending retention on existing data is safe; shortening it causes older data to be deleted eventually. There is no indefinite retention, but very long values such as -retentionPeriod=100y are accepted. Samples with timestamps before 2 January 1970 are rejected, and by default samples more than two days in the future are refused unless -futureRetention is raised.

Single-node VictoriaMetrics does not do application-level replication. High availability there means running two or more identically configured instances, preferably in different availability zones, and having vmagent replicate writes to all of them by listing several -remoteWrite.url flags, then load-balancing reads. The cluster version adds -replicationFactor, but the docs are candid about the cost: replication multiplies CPU, RAM, disk and network use by up to N times, needs at least 2N-1 storage nodes to keep the factor during N-1 failures, requires -dedup.minScrapeInterval=1ms on vmselect, and "doesn't save from disaster." The recommended default is to leave replication to durable replicated disks and to take regular backups.

Upgrades are deliberately simple. The docs say it is safe to upgrade, skip versions and even downgrade unless release notes say otherwise; the procedure is to send SIGINT, wait for a graceful stop and start the new binary. The docs note that Prometheus does not drop data during a VictoriaMetrics restart, and the same applies to vmagent.

How it compares

The README itself frames the alternatives: Prometheus for local storage, Thanos, Cortex and M3DB for scaling Prometheus horizontally, InfluxDB and TimescaleDB as general time series databases, and Graphite for older setups. Against Prometheus, VictoriaMetrics offers longer retention, a cluster mode and broader ingestion protocols while keeping PromQL compatibility. Against Thanos or Cortex, its argument is fewer moving parts: a single binary that the project says covers what would otherwise be a medium-sized cluster, and a cluster mode with three component types and no object-store dependency.

The trade-offs run the other way too. MetricsQL is PromQL-compatible rather than identical, so dashboards that rely on MetricsQL extensions become less portable. And a store built around Prometheus-style metrics is not a general-purpose analytics database; the SQL-based alternatives the README names are better suited to arbitrary joins and relational queries.

Things to know before adopting

• Open-core model. The single-node and cluster versions are Apache-2.0, but several features are Enterprise-only: anomaly detection, backup automation, multiple retentions per dataset, downsampling, automatic vmstorage discovery, and mTLS for vminsert and vmselect. Enterprise binaries are published on GitHub Releases alongside the open-source ones and need a licence (a free trial is offered).
• LTS lines are Enterprise-only. Long-term support releases receive fixes for 12 months, with new lines every six months. Open-source users are expected to track the latest release; the security policy lists only the latest release and LTS releases as supported.
• Fast release cadence. The project says it "evolves fast" and recommends checking the changelog and upgrading regularly. Three releases shipped between 12 and 26 October 2026 alone.
• Network security is the operator's job. All components are meant to run in a private network with no direct internet access. External clients should reach the cluster only through vmauth or vmgateway, with HTTPS for tokens. By default, cluster components talk to each other unencrypted on the assumption that the network is protected.
• Single-node and cluster data formats differ. Moving data from a single node into vmstorage requires re-ingesting it; the docs describe a migration path, but it is not a file copy.
• Tenant metadata lives elsewhere. The cluster identifies tenants only by numeric ids. Names, auth tokens, limits and accounting belong in a separate service in front of the cluster.
• Freshly ingested data is not instantly queryable. The quick-start notes it can take up to 30 seconds for new data to appear in query results, which matters for tests and alert rules that query immediately after writing.
• Disk headroom for retention. Plan storage for retention plus one month, not retention alone.
• Hosted option. VictoriaMetrics Cloud is the vendor's managed service, with automatic upgrades; it is a separate commercial product from the self-hosted binaries.

Project activity

As of October 2026 the repository has about 18,000 stars on GitHub and roughly 1,800 forks. It was created in September 2018, is written in Go and is licensed under Apache-2.0. The latest release at the time of writing is v1.155.0, published on 26 October 2026, and commits land daily. Docker images are published on Docker Hub and Quay, including hardened scratch-based images, and the project runs a Slack community, a subreddit and Telegram channels.

Source code and releases are at github.com/VictoriaMetrics/VictoriaMetrics, documentation at docs.victoriametrics.com, including the quick start guide and cluster documentation, and the project site at victoriametrics.com.