VictoriaMetrics: When Prometheus Gets Too Hungry for Your Hardware

I love Prometheus. I’ve said as much before. But there’s a moment in the life of a growing homelab where the love turns slightly conditional, and that moment usually arrives when you check htop and find Prometheus quietly chewing through two gigabytes of RAM to remember some numbers about your fridge thermometer. It’s not that Prometheus is badly written — it’s that it was designed for ephemeral, short-retention monitoring of large fleets, and it makes memory and disk trade-offs that suit a data centre better than a fanless box in a cupboard.

This is where VictoriaMetrics quietly walks in and asks you to hold its beer.

1 What it actually is

VictoriaMetrics is a time-series database that speaks Prometheus fluently. It ingests data in the Prometheus format, it answers queries in PromQL (and a superset called MetricsQL), and it can be scraped and queried by exactly the tools you already use. From Grafana’s point of view, pointing at VictoriaMetrics instead of Prometheus is a one-line data-source change — the dashboards don’t know or care.

The pitch is simple: same interface, far less hardware. It compresses data more aggressively, uses memory more frugally, and writes to disk in a way that’s kinder to both spinning rust and SD cards. On the same workload that has Prometheus sweating, the single-binary version of VictoriaMetrics will typically sit there using a few hundred megabytes and a fraction of the disk.

2 The single binary is the whole point

Forget the clustered version for a homelab — that’s for people storing billions of series, and you are not that person. The single-node binary is one executable, one data directory, and a handful of flags. Here’s the shape of it in compose:

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:latest
    command:
      - '--storageDataPath=/storage'
      - '--retentionPeriod=12'        # months, not days
      - '--httpListenAddr=:8428'
    volumes:
      - vm_data:/storage
    ports:
      - "8428:8428"

volumes:
  vm_data:

Note that retentionPeriod=12 — that’s twelve months. Long retention is where VictoriaMetrics genuinely shines and where vanilla Prometheus starts crying. Keeping a year of history on Prometheus means either a lot of disk or bolting on Thanos or Cortex, both of which add real operational weight. Here it’s a single flag, and the compression keeps the footprint sane.

3 Two ways to feed it

You have a choice. You can keep your existing Prometheus scraping everything and just tell it to remote_write a copy of every sample to VictoriaMetrics — useful as a long-term store sitting behind a Prometheus you don’t want to disturb:

remote_write:
  - url: http://victoriametrics:8428/api/v1/write

Or — and this is what I eventually did — you drop Prometheus entirely and let VictoriaMetrics do the scraping itself via its bundled agent, vmagent. vmagent reads a Prometheus-style scrape config, so your existing scrape_configs move across untouched:

  vmagent:
    image: victoriametrics/vmagent:latest
    command:
      - '--promscrape.config=/etc/prometheus.yml'
      - '--remoteWrite.url=http://victoriametrics:8428/api/v1/write'
    volumes:
      - ./prometheus.yml:/etc/prometheus.yml

vmagent is also dramatically lighter than Prometheus’s own scraper, and it can buffer to disk if the database is briefly unreachable — handy when you’re restarting things.

4 Querying feels identical, mostly

In Grafana, set the data source type to Prometheus and the URL to http://victoriametrics:8428 and everything works. Your old PromQL queries run unchanged. MetricsQL adds a few conveniences — rate() that handles counter resets more gracefully, WITH templates so you stop copy-pasting the same subexpression — but you can ignore all of it and pretend you’re still writing PromQL.

The alerting story is handled by vmalert, a companion binary that evaluates the same recording and alerting rules Prometheus uses and forwards firing alerts to Alertmanager. So your existing alert rules also survive the move.

5 Where it isn’t a free lunch

Honesty time. VictoriaMetrics is developed by a company, and while the core is genuinely open source under Apache 2.0, some enterprise features (downsampling, certain cluster bits) are not. For a homelab that’s irrelevant — everything you need is in the open core — but it’s worth knowing the model.

It’s also subtly different from Prometheus under load and in edge cases: histogram handling, staleness, and a few MetricsQL-versus-PromQL quirks can surprise you if you’re porting complex dashboards. And because it’s “Prometheus-compatible” rather than “Prometheus,” the occasional third-party tool that pokes Prometheus’s internal API directly won’t be happy. These are corner cases, but they exist.

6 The verdict

If you’re running a handful of nodes and Prometheus is using more RAM than you’d like, or you want a year of metrics without standing up Thanos, switch. VictoriaMetrics is the closest thing to a free upgrade I’ve found in the monitoring world: same dashboards, same queries, same alerts, a fraction of the resources, and far longer retention thrown in. I migrated a memory-starved mini-PC to it over a wet Sunday afternoon, the graphs looked identical, and the RAM graph for the box itself dropped off a cliff. That’s the most satisfying kind of change — the one nobody but you ever notices.