VictoriaMetrics

What it is

An Apache-2.0 licensed time-series database for metrics, compatible with the Prometheus data model, remote write protocol and query language. Available as a single binary or as a cluster of three component types.

Architecture

Data is stored in per-month partitions with columnar compression, and background merges combine parts — an LSM-like design where retention is a partition drop. The single-node binary handles substantial ingestion; the cluster version splits into vminsert, vmstorage and vmselect.

Best use cases

• Infrastructure and application metrics at scale, replacing or sitting behind Prometheus.
• Long-term storage for Prometheus, via remote write.
• Consolidating metrics from highly-available Prometheus pairs, using its deduplication.
• Deployments where storage cost per sample is a significant consideration.

When not to use it

• As a general-purpose database — it is a metrics store, not a system of record.
• For non-metric time-series data needing joins against relational data; TimescaleDB fits better.
• For event or log data with high-cardinality attributes, which belongs in a search or column store.

Data model

Prometheus-compatible: a metric name plus label key-value pairs identifies a series, holding timestamped float values. Ingest accepts Prometheus remote write, native scraping, InfluxDB line protocol, Graphite and OpenTSDB.

Consistency and transactions

No transactions; this is an append-oriented metrics store. Out-of-order and duplicate samples are accepted and deduplicated on read according to the configured interval, which is what makes consolidating redundant Prometheus instances straightforward.

Scaling model

Vertical first — the single-node binary goes a long way and avoids an entire class of operational concerns. The cluster version scales ingestion and query independently across vminsert, vmstorage and vmselect.

Replication

The cluster version replicates across vmstorage nodes at a configurable factor. A common alternative is redundancy at the collection layer: two independent instances receiving the same data, deduplicated at query time.

Backup and recovery

vmbackup and vmrestore, with incremental backups against a previous one. Snapshots are created via the HTTP API and must be deleted after copying. Restore requires the service to be stopped.

Monitoring

Its own metrics at /metrics, with official Grafana dashboards. Watch ingestion rate, active series in the index cache, slow inserts, rejected rows, free disk, and — for vmagent — pending buffered data.

Common mistakes

Production checklist

See Time Series Production Checklist.

Related guides