VictoriaMetrics: A Faster Prometheus for Your Homelab

Prometheus is the standard for homelab metrics, but it has limits: high memory usage, slow queries on large datasets, and a storage format that isn't optimized for long-term retention. VictoriaMetrics solves all three.

Photo by Denny Müller on Unsplash

VictoriaMetrics is a drop-in Prometheus replacement that's 5-10x more efficient in memory and disk usage, with query performance that scales better as your metric history grows. It also speaks the Prometheus query language (PromQL), so your existing Grafana dashboards keep working.

Why Switch from Prometheus?

For a homelab monitoring dozens of nodes and services, this means you can run VictoriaMetrics on a fraction of the RAM Prometheus would require and keep data for months instead of weeks.

Single-Node Docker Setup

The simplest deployment — a single VictoriaMetrics instance:

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:stable
    container_name: victoriametrics
    ports:
      - "8428:8428"
    volumes:
      - vm_data:/storage
    command:
      - "--storageDataPath=/storage"
      - "--retentionPeriod=12"   # months
      - "--httpListenAddr=:8428"
    restart: unless-stopped

volumes:
  vm_data:

VictoriaMetrics exposes:

• http://localhost:8428/api/v1/query — PromQL queries
• http://localhost:8428/metrics — its own metrics
• http://localhost:8428/vmui — built-in query UI

Replacing Prometheus

VictoriaMetrics accepts Prometheus remote_write, so you can either:

1. Replace Prometheus entirely (use VictoriaMetrics as the scraper), or
2. Keep Prometheus as the scraper and use VictoriaMetrics for long-term storage

Option 1: Replace Prometheus Entirely

VictoriaMetrics can scrape targets directly with a Prometheus-compatible config:

Create prometheus.yml (same format as Prometheus):

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'homelab-nodes'
    static_configs:
      - targets:
        - '192.168.1.10:9100'
        - '192.168.1.11:9100'
        - '192.168.1.12:9100'

Then pass the config to VictoriaMetrics:

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:stable
    volumes:
      - vm_data:/storage
      - ./prometheus.yml:/prometheus.yml:ro
    command:
      - "--storageDataPath=/storage"
      - "--promscrape.config=/prometheus.yml"
      - "--retentionPeriod=12"

Option 2: Prometheus Writes to VictoriaMetrics

Keep your existing Prometheus setup and add VictoriaMetrics as the long-term store. Add remote_write to prometheus.yml:

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

Prometheus scrapes and alerts as usual, but data is also written to VictoriaMetrics for long-term queries.

Grafana Integration

VictoriaMetrics is compatible with Grafana's Prometheus datasource:

1. In Grafana: Connections → Add new data source → Prometheus
2. URL: http://victoriametrics:8428
3. Leave everything else default
4. Click Save & test

Your existing Prometheus dashboards (Node Exporter Full, cAdvisor, etc.) work without changes.

Alternatively, use the native VictoriaMetrics Grafana plugin for additional features, including MetricsQL (VictoriaMetrics' extended query language).

VMAgent: Lightweight Scraper

For edge nodes or reducing VM's load, VMAgent scrapes targets and forwards to VictoriaMetrics:

services:
  vmagent:
    image: victoriametrics/vmagent:stable
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    command:
      - "--promscrape.config=/etc/prometheus/prometheus.yml"
      - "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
    restart: unless-stopped

VMAgent uses 10-15MB of RAM, making it practical on Raspberry Pis and small edge nodes that would struggle with full Prometheus.

Alerting with VMAlert

VictoriaMetrics doesn't include an alertmanager, but vmalert evaluates alert rules:

services:
  vmalert:
    image: victoriametrics/vmalert:stable
    volumes:
      - ./alerts:/alerts:ro
    command:
      - "--datasource.url=http://victoriametrics:8428"
      - "--remoteRead.url=http://victoriametrics:8428"
      - "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
      - "--notifier.url=http://alertmanager:9093"
      - "--rule=/alerts/*.yml"
    restart: unless-stopped

Alert rules use the same Prometheus alerting format:

# alerts/node.yml
groups:
  - name: node
    rules:
      - alert: HighCPU
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU on {{ $labels.instance }}"

Storage Efficiency

VictoriaMetrics' compression is aggressive. For a homelab monitoring 10 servers with ~1000 metrics each at 15-second intervals:

• Prometheus: ~50GB/year
• VictoriaMetrics: ~8–12GB/year

The --retentionPeriod flag (in months or weeks) lets you keep much longer histories on the same disk.

When to Stick with Prometheus

VictoriaMetrics is an upgrade in almost every dimension, but Prometheus has deeper ecosystem integration — particularly with Kubernetes-native tooling like the Prometheus Operator and kube-prometheus-stack. If your homelab runs complex Kubernetes workloads, start with kube-prometheus-stack and add VictoriaMetrics as a remote write target.

For everything else — bare-metal nodes, Docker Compose services, IoT sensors — VictoriaMetrics is the better choice.