VictoriaMetrics vs Prometheus

Quick verdict

This page is for engineers running Prometheus-style monitoring who are deciding whether to keep everything in Prometheus or add (or switch to) VictoriaMetrics, for servers and services and sometimes for building or plant metrics alongside them. For the difference between a monitoring system and a sensor historian, see InfluxDB vs Prometheus.

Prometheus, a Cloud Native Computing Foundation project under Apache 2.0, pulls metrics over HTTP from instrumented applications and exporters, stores them in a local TSDB, evaluates recording and alerting rules written in PromQL and sends alerts to a separate Alertmanager. Version 3.16.0 was released on 4 November 2026.

VictoriaMetrics is a time-series database written in Go, also under Apache 2.0 for both its single-node and cluster versions, with an Enterprise edition sold separately. Around the database the project ships vmagent (collection and remote write with on-disk buffering), vmalert (recording and alerting rules), vmauth (authenticating proxy) and vmbackup and vmrestore. The latest release in the changelog when checked was v1.155.0. See the VictoriaMetrics guide.

Side by side

Key differences

Replacement, or long-term storage behind Prometheus

The two are often used together rather than chosen between. Prometheus keeps scraping and evaluating rules locally and streams samples from its write-ahead log to a remote endpoint with remote_write; if the endpoint is down, failures are retried without loss for up to about two hours. VictoriaMetrics accepts that stream and serves PromQL-compatible queries to Grafana, so dashboards point at VictoriaMetrics for history while Prometheus handles the last few hours. Prometheus's agent mode turns it into a scrape-and-forward agent with local querying, alerting and storage disabled.

# Illustrative configuration, not run here: prometheus.yml keys from the Prometheus
# documentation; the VictoriaMetrics single-node write path is from its documentation;
# the host name is a placeholder. Check both against the documentation for your versions.
remote_write:
  - url: "http://victoriametrics.monitoring.local:8428/api/v1/write"

Going further, vmagent can scrape Prometheus-format targets itself, buffer on local disk when the remote store is unreachable, and write to VictoriaMetrics, while vmalert evaluates recording and alerting rules and sends alerts to an Alertmanager. At that point Prometheus is no longer in the path, though its exporters, rule files and Alertmanager still are.

Storage, retention and scaling

Prometheus stores data in two-hour blocks compacted in the background, keeps 15 days unless told otherwise, and documents that local storage is not clustered or replicated and that NFS is not supported. Scaling means splitting targets across servers or adding Thanos or Grafana Mimir for long-term, global, highly available storage.

VictoriaMetrics writes immutable parts into monthly partitions, merges them in the background and keeps a per-partition inverted index (indexDB). Retention is one value per instance in open source (31 days by default), so different retentions mean separate instances routed through vmauth; per-label retention filters are an Enterprise feature. The cluster version splits ingestion (vminsert), storage (vmstorage, shared-nothing) and queries (vmselect), adds multi-tenancy and can return partial results if a storage node is down. The documentation itself recommends the single-node version below about a million data points per second because it is simpler to run.

Queries, deduplication and downsampling

PromQL works on both. MetricsQL is backwards-compatible with PromQL, so Grafana dashboards built for Prometheus keep working, and adds functions plus some intentional differences that the MetricsQL documentation lists; check your panels against that list before migrating. Deduplication is a VictoriaMetrics feature: with -dedup.minScrapeInterval set to the scrape interval, two redundant collectors writing the same series leave one sample per interval (the latest timestamp, then the larger value). With Prometheus, two HA servers each keep their own copy.

# Illustrative queries, not run here: valid PromQL and MetricsQL, adapted from the
# Prometheus and MetricsQL documentation.
rate(http_requests_total{job="api"}[5m])
avg_over_time(ahu_supply_air_temp_c{building="hq"}[15m])

Downsampling in Prometheus is done with recording rules that write lower-resolution series. In VictoriaMetrics open source the same approach uses vmalert recording rules into a long-retention instance; automatic downsampling of old data is an Enterprise feature.

Ingestion formats and out-of-order data

Prometheus is pull-first: the Pushgateway is recommended essentially only for service-level batch jobs, and the remote write and OTLP receivers are off by default because Prometheus may run without authentication. Its TSDB setting out_of_order_time_window defaults to 0s, so out-of-order samples are rejected unless you configure a window, which matters when a collector replays a buffer.

VictoriaMetrics is built to receive pushes in many formats: Prometheus remote write, InfluxDB line protocol over HTTP, TCP and UDP, Graphite, OpenTSDB, OpenTelemetry, DataDog and New Relic agents, JSON lines, CSV and a native format, alongside scraping through vmagent. InfluxDB line protocol fields become separate series named {measurement}_{field} and non-numeric field values are converted to 0, so text states must be encoded as numbers. That makes VictoriaMetrics a reasonable home for numeric building or plant metrics next to IT metrics, but not for text events or relational records; see the VictoriaMetrics guide.

Editions, security and operations

Prometheus has no paid edition. TLS and basic authentication are configured through a web configuration file (--web.config.file), which the documentation still marks as experimental; each server is standalone and does not depend on network storage, which is why the project positions it as the system you use during an outage.

VictoriaMetrics open source covers both single-node and cluster versions. Enterprise adds downsampling, multiple retentions per label filter, anomaly detection, backup automation, mTLS between cluster components and long-term support releases; Enterprise binaries are public but need a licence key, and the documentation permits evaluation in non-production setups with a trial licence and production use with an enterprise contract or permit. The documentation says all components must run in protected private networks, with requests from untrusted networks going through an authenticating proxy such as vmauth with TLS. Not legal advice: this summarises the licence and documentation; read them for your situation.

Pricing and licensing

Prometheus is free and open source under Apache 2.0, with no paid edition; your costs are servers, disks and the people who run them, plus Thanos or Mimir infrastructure if you add long-term storage. Several cloud providers sell managed Prometheus-compatible services; check each provider's pricing page, since we did not compare them here.

VictoriaMetrics open source (single-node and cluster) carries no licence fee. VictoriaMetrics Enterprise is priced through sales, with a trial licence for non-production evaluation; no prices are published. VictoriaMetrics Cloud, the managed service, is billed on fixed capacity tiers metered hourly plus storage and network egress, according to its billing documentation. The entry price differed between sources when checked (the billing documentation said about USD 190 a month for the smallest tiers, the product page "from USD 200 a month" for the first VictoriaMetrics tier), so check the cost preview in the console for your configuration.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You need a complete sensor record with strings, device timestamps and SQL: see InfluxDB vs Prometheus and TimescaleDB vs InfluxDB.
• You want a managed observability platform rather than running servers: see Prometheus vs Datadog.
• Device-centred industrial telemetry with SQL windows: see InfluxDB vs TDengine.
• You are comparing database monitoring products rather than metrics stores: see the open source database monitoring tools.

Final recommendation

Frequently asked questions

Sources

• VictoriaMetrics documentation: single-node version
• VictoriaMetrics documentation: cluster version
• VictoriaMetrics documentation: MetricsQL
• VictoriaMetrics documentation: Enterprise
• VictoriaMetrics Cloud: billing
• VictoriaMetrics releases on GitHub
• Prometheus: overview
• Prometheus: storage
• Prometheus: remote write tuning
• Prometheus releases on GitHub

Checked November 2026.

How we research comparisons: our editorial method.