VictoriaMetrics ships eight binaries from one Makefile, and keeps the tiered storage features out of the Apache build

Eight binaries come out of one Makefile, each with prod and pure variants

VictoriaMetrics is not one program. The root Makefile builds eight separate executables under a single aggregate target:

all: \
	victoria-metrics-prod \
	vmagent-prod \
	vmalert-prod \
	vmalert-tool-prod \
	vmauth-prod \
	vmbackup-prod \
	vmrestore-prod \
	vmctl-prod

The naming is consistent across the file. There is a `vmutils` target for the non-database half of the family, a `vmutils-pure` target for the same set built with the pure suffix, a `vmutils-linux-amd64` target for a narrower platform, and parallel `publish` and `package` targets that mirror the same eight names. The individual targets themselves are not in the root file. It includes `app/*/Makefile`, `deployment/*/Makefile`, `benchmarks/Makefile`, `package/release/Makefile`, plus `codespell/Makefile`, `docs/Makefile` and `dashboards/Makefile`, so the real build rules live in per-application directories.

Consequence for you: the eight binaries share one repository and one build. Pinning a VictoriaMetrics version pins vmagent, vmalert, vmauth, vmbackup, vmrestore and vmctl to the same tag, whether or not you use all of them.

The drop-in Prometheus replacement vendors Prometheus into its own tree

The project describes itself as a drop-in replacement for Prometheus and as a long term store for it, and go.mod shows what that costs. `github.com/prometheus/prometheus` is pinned as a direct dependency at v0.315.0, alongside first party modules from the same organisation: `VictoriaMetrics/easyproto`, `fastcache`, `metrics` and `metricsql`, plus a pseudo-version of `VictoriaMetrics/VictoriaLogs` that carries a commit hash rather than a tag.

The repository also has a `vendor/` directory at the top level and a `go.sum` beside go.mod, which means the dependency graph is checked in rather than resolved at build time. The module file targets Go 1.27.3.

Consequence for you: you are adopting a copy of Prometheus's own code inside your monitoring system, at a version the project chooses. That buys build reproducibility and removes network access from the build, and it also means Prometheus changes reach you when this project decides to take them, not when upstream ships them. Anyone auditing dependencies for a supply chain review should read the `vendor/` tree, not the module proxy.

Three cloud SDKs and an NFS path, which moves the failure mode to the filesystem

Storage is where a time series database earns its keep, and go.mod names the cloud storage SDKs it depends on. `github.com/aws/aws-sdk-go-v2` appears with its config, S3 manager and S3 service modules, the Azure SDK contributes `azcore`, `azidentity` and `azblob`, and `cloud.google.com/go/storage` covers Google Cloud Storage. A `ports/` directory sits in the repository root alongside `app/`, `lib/` and `deployment/`.

On top of the object stores, the feature list names NFS-based storage explicitly, with Amazon EFS and Google Filestore given as the examples. That is a documented, supported placement rather than an accident, and it is a different durability story from writing to local disk.

Consequence for you: if you place the data directory on NFS, the latency and consistency behaviour of that filesystem becomes part of your query and ingest performance. The same go.mod also pulls in compression and encoding libraries, `klauspost/compress`, `golang/snappy` and `valyala/gozstd`, so storage cost is addressed in code, but only the open source build has one retention window to spend it on.

MetricsQL runs beside PromQL, and Grafana can read it as Prometheus or Graphite

The query layer carries two languages. PromQL is supported for compatibility, and MetricsQL is described as the more performant of the two. Both are in the module graph through `VictoriaMetrics/metricsql`, and the same code also imports `cel.dev/expr` indirectly, which is the expression engine behind common filter style expressions.

The Grafana story is the one that decides the migration path. The project positions itself as a drop-in replacement for both Prometheus and Graphite in Grafana, which means an existing dashboard pointed at Prometheus can be repointed without rewriting queries. It also describes a global query view: multiple Prometheus instances or any other data sources may ingest into VictoriaMetrics and be queried through a single query, so the same instance can be the store for more than one source.

Consequence for you: adopting it as a store behind an existing Prometheus means your exporters keep working and Grafana keeps its datasource, but your query path now depends on a second language with its own semantics. The gap between PromQL and MetricsQL is where dashboards written by someone else tend to need rework.

Retention tiers, downsampling and automated backup are not in the Apache build

This is the sharpest boundary in the project. The single-node and cluster versions are both open source under Apache License 2.0, and the README says so explicitly. The Enterprise version is a separate set of features on top:

- Anomaly detection, described as simplifying alerting rules by covering complex anomalies found in metrics data - Backup automation for regular backup procedures - Multiple retentions, specifying different retentions for different datasets to reduce storage cost - Downsampling, also aimed at storage cost

Enterprise builds and long term support releases are publicly available to evaluate under a free trial license, and commercial support is offered separately. Open source backup is a different mechanism: the feature list points at instant snapshots rather than scheduled jobs, and `vmbackup` and `vmrestore` exist as standalone binaries in the open source set.

Consequence for you: an Apache-licensed VictoriaMetrics install has one retention setting. If you are running it as a long term Prometheus store, high resolution recent data and coarse old data in the same database is a paid feature. The instant snapshot path gives you a way to copy consistent data, but the schedule, the retention tiers and the downsampling rules are not in the build you get under Apache 2.0.

The build shells out to git, getconf, date and openssl before it compiles

Before any Go compiler runs, the root Makefile assembles a version string from the surrounding system:

BUILDINFO_TAG ?= $(shell echo $$(git describe --long --all | tr '/' '-')$$( \
	      git diff-index --quiet HEAD -- || echo '-dirty-'$$(git diff-index -u HEAD | openssl sha1 | cut -d' ' -f2 | cut -c 1-8)))

The logic is readable. It takes the tag pointing at HEAD if one exists, otherwise it falls back to `git describe`, and when the working tree differs from HEAD it appends a dirty marker plus the first eight characters of an `openssl sha1` of the diff. Concurrency comes from `getconf _NPROCESSORS_ONLN`, the timestamp from `date -u`, and the result is injected into the binary through `GO_BUILDINFO` as `lib/buildinfo.Version`. Linting is pinned separately with `GOLANGCI_LINT_VERSION := 2.14.0`.

Consequence for you: a build in a source archive without `.git` has no tag and no describe output, so the version string degrades. Reproducing someone else's build means matching that dirty-tree hash, which is only reported when the tree is not clean.

There is no install command anywhere, only three distribution channels

The README names where to get the software. It lists binary releases on the GitHub releases page, Docker images on Docker Hub and on Quay, and the source code. Deployment comes in two documented types, a single-node version and a cluster version, both under Apache 2.0. The project states that configuration is through command-line flags with a default that is already fine tuned.

The consequences run in both directions. For a reader, choosing how to run it is left entirely to you, and a first deployment is a decision between a binary on a host, a container image from one of two registries, or a build from source with the toolchain assumptions in the previous section. For an operator, the command-line flags are the configuration surface the README names.

The same applies to upgrades. The project says it evolves fast and points to a changelog and a how to upgrade page in its own documentation. A deployment decision is therefore a documentation decision, and the README is a map rather than a manual.

Editorial conclusion

VictoriaMetrics is a defensible choice when you want to keep Prometheus metrics long term, ingest from more than one protocol at once, or query several Prometheus instances through a single endpoint, and when you are willing to run the upgrade procedure the project documents separately from its README. It is a weaker fit if you need multiple retention windows, downsampling, or automated backup on day one, because those live in the Enterprise edition and the free trial license is how you evaluate them. Before committing, check three things: which retention your data volume actually needs, whether the ingestion protocols you already use are on the supported list, and what the upgrade path costs you, since the project states that it evolves fast and points the upgrade procedure at its own documentation rather than the README.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. VictoriaMetrics/VictoriaMetrics on GitHub