VictoriaMetrics: Prometheus-Compatible Time Series Database

VictoriaMetrics is a high-performance, cost-effective time series database that serves as a drop-in replacement for Prometheus. It offers better compression (up to 10x), lower memory usage, and faster queries while maintaining full PromQL compatibility. This guide covers deploying VictoriaMetrics as a Prometheus alternative or long-term storage backend.

Single-Node Installation

# Download
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.99.0/victoria-metrics-linux-amd64-v1.99.0.tar.gz
tar xzf victoria-metrics-linux-amd64-v1.99.0.tar.gz
sudo mv victoria-metrics-prod /usr/local/bin/

# Run
victoria-metrics-prod \
    -storageDataPath=/data/victoria-metrics \
    -retentionPeriod=12    # 12 months retention
    -httpListenAddr=:8428

Docker Deployment

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.99.0
    ports:
      - "8428:8428"
    volumes:
      - vm_data:/storage
    command:
      - "--storageDataPath=/storage"
      - "--retentionPeriod=12"
      - "--httpListenAddr=:8428"

volumes:
  vm_data:

Replacing Prometheus

# VictoriaMetrics can scrape targets directly (no Prometheus needed)
# Create prometheus.yml compatible config:

# /etc/victoriametrics/promscrape.yml
scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['localhost:9100']
  - job_name: mysql
    static_configs:
      - targets: ['localhost:9104']

# Run with scraping enabled
victoria-metrics-prod \
    -storageDataPath=/data/vm \
    -promscrape.config=/etc/victoriametrics/promscrape.yml \
    -retentionPeriod=12

As Prometheus Remote Storage

# Keep Prometheus for scraping, use VictoriaMetrics for storage
# prometheus.yml
remote_write:
  - url: http://victoriametrics:8428/api/v1/write

# Query VictoriaMetrics in Grafana
# Add data source: Prometheus
# URL: http://victoriametrics:8428

MetricsQL (PromQL Superset)

# VictoriaMetrics supports PromQL plus extensions:

# Rollup functions (aggregate over time)
rollup_rate(http_requests_total[5m])

# Range query over subquery
avg_over_time(rate(cpu_usage[5m])[1h:5m])

# Keep metric names through transformations
keep_metric_names(rate(http_requests_total[5m]))

# Label manipulation
label_set(up, "env", "production")
label_del(metric, "unwanted_label")

Cluster Mode

# For high availability and horizontal scaling:
# vminsert — accepts incoming data
# vmselect — handles queries
# vmstorage — stores time series data

services:
  vmstorage:
    image: victoriametrics/vmstorage
    command: --storageDataPath=/storage --retentionPeriod=12
    volumes:
      - storage_data:/storage

  vminsert:
    image: victoriametrics/vminsert
    command: --storageNode=vmstorage:8400
    ports:
      - "8480:8480"

  vmselect:
    image: victoriametrics/vmselect
    command: --storageNode=vmstorage:8401
    ports:
      - "8481:8481"

Performance Comparison

• Storage: VictoriaMetrics uses 5-10x less disk space than Prometheus
• Memory: 2-5x lower RAM usage for the same workload
• Query speed: Faster for large time ranges and high-cardinality queries
• Ingestion: Handles 1M+ samples/second on a single node

Best Practices

• Use VictoriaMetrics for long-term storage (months/years) where Prometheus struggles
• Set -retentionPeriod based on your compliance and capacity requirements
• Use vmagent (lightweight scraper) instead of full Prometheus for data collection
• Enable deduplication (-dedup.minScrapeInterval) when scraping the same targets from multiple agents
• Monitor VictoriaMetrics itself using its /metrics endpoint