Prometheus vs VictoriaMetrics
Prometheus vs VictoriaMetrics compared on storage, retention, high availability, clustering, PromQL vs MetricsQL, agents, alerting and enterprise features, using Prometheus 3.15.1 and VictoriaMetrics v1.154.1.
Quick Answer
Keep Prometheus if one server per cluster with a few weeks of retention covers you: it is the reference implementation of PromQL, ships an OTLP receiver and an LTS line, and every exporter and dashboard targets it. Add or switch to VictoriaMetrics when you need months of retention, one place to query many Prometheus servers, or a horizontally scaled cluster: it accepts Prometheus remote write, scrapes prometheus.yml, answers the Prometheus query API and keeps 31 days by default. Downsampling and multiple retentions are Enterprise-only.
Last updated October 26, 2026. Covers Prometheus 3.15.1 and 3.13.5 LTS (21 Oct 2026) and VictoriaMetrics v1.154.1 (19 Oct 2026), with the Prometheus storage, agent, OTLP and release-cycle docs and the VictoriaMetrics single-node, cluster, MetricsQL, vmagent, vmalert and Enterprise docs.
| Feature | Prometheus | VictoriaMetrics |
|---|---|---|
| Licence | Apache-2.0 | Apache-2.0 (community); commercial Enterprise edition |
| Latest Release (Oct 2026) | v3.15.1 (21 Oct 2026) | v1.154.1 (19 Oct 2026) |
| Long-Term Support | Yes: 3.13 LTS until 31 Jul 2027; minors every 6 weeks | LTS releases with Enterprise |
| Storage Model | Local TSDB with WAL, single node | Single-node binary or vminsert/vmselect/vmstorage cluster |
| Default Retention | 15 days (time or size based) | 31 days (-retentionPeriod, min 24h) |
| High Availability | Run duplicate servers; Alertmanager clusters and deduplicates alerts | Cluster -replicationFactor or replicated disks; vmagent can write to two instances |
| Horizontal Scaling | Not built in (remote storage needed) | Yes (cluster version) |
| Query Language | PromQL (reference) | MetricsQL (PromQL-compatible superset) + Prometheus query API |
| Ingestion Protocols | Scrape (Prometheus/OpenMetrics), OTLP receiver, remote write receiver | Prometheus remote write, OTLP, Influx, Graphite, OpenTSDB, DataDog, NewRelic, CSV, JSON |
| Scraping | Built in, full service discovery | Built in (-promscrape.config) and in vmagent |
| Lightweight Agent | Agent mode (--agent): no querying, alerting or local storage | vmagent: relabeling, disk buffering, stream aggregation, multi-remote |
| Alerting / Recording Rules | Built-in rules engine + Alertmanager | vmalert (Prometheus rule syntax) + Alertmanager |
| Multi-Tenancy | No | Cluster version (accountID/projectID) |
| Downsampling | Enterprise only | |
| Backups | TSDB snapshot endpoint (needs --web.enable-admin-api) | vmbackup/vmrestore snapshots; automation in Enterprise |
Prometheus
Apache-2.0-licensed monitoring system and time-series database written in Go. It scrapes targets, stores samples in a local TSDB, evaluates PromQL and recording/alerting rules, and hands alerts to Alertmanager.
Pros
- Reference implementation of PromQL; every exporter, Helm chart and Grafana dashboard assumes it
- LTS line: 3.13 is supported until 31 Jul 2027, and 3.13.5 shipped alongside 3.15.1 on 21 Oct 2026
- Native OTLP receiver (--web.enable-otlp-receiver) at /api/v1/otlp/v1/metrics, with resource-attribute promotion
- Agent mode (--agent) turns the same binary into a scrape-and-forward agent with a WAL buffer
- Remote write and remote read let you keep Prometheus at the edge and put long-term data elsewhere
- 3.15 added Unix socket scraping, the OpenMetrics 2.0 scrape format and a stable XOR2 chunk encoding
Cons
- The storage docs say local storage is not clustered or replicated and is not durable against drive or node outages
- Default retention is 15 days; longer history means more local disk or a remote storage system
- No built-in global view across many Prometheus servers; that takes Thanos, Cortex, Mimir or VictoriaMetrics
- No downsampling in Prometheus itself
- OTLP receiver is off by default because Prometheus has no built-in authentication
Best For
One Prometheus per cluster or environment with days to weeks of retention, and teams that want the standard, vendor-neutral setup.
VictoriaMetrics
Apache-2.0-licensed time-series database and monitoring stack written in Go, available as a single-node binary or a vminsert/vmselect/vmstorage cluster, with vmagent, vmalert and vmauth as companions and a paid Enterprise edition.
Pros
- Drop-in remote storage for Prometheus and implements the Prometheus query API, so Grafana's Prometheus datasource keeps working
- Single-node binary can scrape a prometheus.yml itself via -promscrape.config
- Default retention is 31 days, with a single -retentionPeriod flag for longer
- Ingests Prometheus remote write, InfluxDB line protocol, Graphite, OpenTSDB, OpenTelemetry, DataDog, NewRelic, CSV and JSON
- Cluster version scales vmstorage horizontally, adds -replicationFactor and multi-tenancy via accountID/projectID
- vmagent buffers to disk when remote storage is down and can replicate to several remote-write targets
Cons
- Downsampling, multiple retentions, backup automation and mTLS between cluster components are Enterprise-only
- MetricsQL differs from PromQL in edge cases: no rate/increase extrapolation and NaN results are dropped
- The cluster needs at least 2N-1 vmstorage nodes to keep replication factor N with N-1 nodes down, and the docs suggest 10+ storage nodes
- Single-node has no replication; durability depends on the disk underneath plus vmbackup snapshots
- Its resource-efficiency figures (up to 7x less RAM and storage than Prometheus) are the vendor's own claims
Best For
Long retention, many Prometheus servers that need one query endpoint, high-cardinality workloads, and teams that want to scale out metrics storage without Thanos or Mimir.
Where Prometheus storage stops
Prometheus keeps samples in a local TSDB, with a write-ahead log protecting data that is still in memory. Its storage docs are direct about the limits: local storage is not clustered or replicated, so it is not arbitrarily scalable or durable in the face of drive or node outages. Retention defaults to 15 days unless you set --storage.tsdb.retention.time or --storage.tsdb.retention.size, and the docs estimate 1 to 2 bytes per sample for sizing disk. The usual answer to these limits is remote write. Prometheus sends every ingested sample to a remote endpoint and can read it back with remote read, so the local TSDB becomes a short buffer while history lives elsewhere. Prometheus can also run in agent mode with --agent, which disables querying, alerting and local storage and keeps only a WAL until data is delivered. For availability, there is no built-in replication; the common pattern is to run two identical Prometheus servers. Alertmanager handles the duplicate alerts: its docs say it deduplicates, groups and routes alerts from clients such as Prometheus, and that Alertmanagers can form their own HA cluster. Prometheus should be pointed at the full list of Alertmanagers, not at a load balancer. Querying two replicas or many clusters as one is where Thanos, Mimir or VictoriaMetrics comes in.
VictoriaMetrics single-node versus cluster
VictoriaMetrics ships the same storage engine in two shapes. Single-node is one binary that accepts Prometheus remote write and many other protocols, answers the Prometheus query API, and can scrape targets from a prometheus.yml with -promscrape.config. Its -retentionPeriod defaults to 31 days with a 24-hour minimum. Backups are instant snapshots archived with vmbackup and restored with vmrestore. The cluster splits work across vminsert, vmselect and vmstorage. vminsert spreads series across storage nodes by consistent hashing on the metric name and labels, vmselect fans queries out to all storage nodes, and storage nodes share nothing. Durability is left to the disks by default; -replicationFactor=N on vminsert stores N copies on distinct nodes, which needs at least 2N-1 vmstorage nodes to tolerate N-1 failures and can multiply resource use by up to N. The docs add that replication does not replace backups. The cluster also brings multi-tenancy, with tenants identified by accountID and optional projectID and created on first write. The docs recommend single-node below about a million data points per second ingestion because it is simpler to run, and suggest at least 10 vmstorage nodes if you do run a cluster.
PromQL versus MetricsQL in practice
VictoriaMetrics describes MetricsQL as backwards-compatible with PromQL, so dashboards built on Grafana's Prometheus datasource should keep working after pointing them at VictoriaMetrics. The differences that show up in real dashboards are documented. First, MetricsQL does not extrapolate rate() and increase(). Prometheus extrapolates to the window edges, so a counter that went up by 3 can show a fractional increase such as 3.2; MetricsQL returns the integer you expect. It also counts the last raw sample before the lookbehind window, which Prometheus ignores. Alerts with thresholds tuned against Prometheus output can therefore fire slightly differently, so recheck them during migration. Second, MetricsQL drops NaN values from results, where Prometheus returns NaN series. Grafana draws nothing for NaN anyway, so graphs usually look the same, but alert expressions that test for NaN behave differently. Third, MetricsQL lets you omit the square-bracket window in rollup functions and picks one from the step and scrape interval, and it adds functions PromQL lacks. Using them ties your queries to VictoriaMetrics, so teams that want to stay portable often restrict themselves to PromQL syntax. The docs ask users to file issues for any other PromQL discrepancy.
Agents, alerting and the Enterprise line
On the collection side, both projects have an agent. Prometheus agent mode keeps Prometheus's service discovery and relabeling and forwards everything over remote write. vmagent does the same with Prometheus-style scrape configs, and adds disk buffering at -remoteWrite.tmpDataPath when the remote is down, replication or sharding across several remote-write targets, and stream aggregation before data leaves the node. It switches to the standard Prometheus remote write protocol when the target is not VictoriaMetrics, so it can also feed other backends. For rules, Prometheus evaluates alerting and recording rules in-process. VictoriaMetrics moves this to vmalert, which uses Prometheus rule syntax, queries one datasource over the Prometheus HTTP API, writes recording-rule results by remote write and sends alerts to the same Alertmanager. Existing rule files usually move over unchanged. The catch is the Enterprise edition. Downsampling, multiple retention periods, backup automation, anomaly detection, mTLS between cluster components, Kafka and Google PubSub integrations, multi-tenant vmalert, advanced vmauth features and FIPS builds are Enterprise-only, with pricing by contact and trial licences for non-production evaluation. If keeping a year of data cheaply depends on downsampling, price Enterprise before you commit.
Verdict
Use Prometheus on its own if each cluster or environment has one Prometheus, you query them separately, and 15 days to a few weeks of history is enough. It is the standard, it has an LTS line, and nothing in your exporters, alerts or dashboards needs translating. Add VictoriaMetrics as remote storage once you need months of retention, a single query endpoint across many Prometheus servers or clusters, or storage that survives the loss of one node; keep Prometheus or switch to vmagent for scraping. Replace Prometheus outright with single-node VictoriaMetrics when you want one binary that scrapes, stores and serves queries with a 31-day default and simple retention settings. Go to the VictoriaMetrics cluster only when ingestion approaches a million data points per second, the threshold below which its own docs recommend single-node. If you need downsampling, budget for VictoriaMetrics Enterprise or look elsewhere.