TS-05 // VM-METRICS // LSM-TREE METRICS STORAGE • CARDINALITY RAM SIZING

VictoriaMetrics vs Prometheus Disk & Cardinality RAM Sizing Dossier

TimescaleOps deterministic sizing equations for bytes-per-sample, active time-series cardinality RAM, and remote_write NVMe storage on VictoriaMetrics vs Prometheus.

Per Prometheus and VictoriaMetrics storage documentation, vanilla Prometheus TSDB averages ~1.3 to 2.2 bytes per sample and expands memory footprint during WAL replay under high label churn, whereas VictoriaMetrics LSM-tree block merges condense monotonic counters to ~0.4 to 0.8 bytes per sample.

TimescaleOps Deterministic Hardware & Partition Sizing Ledger: TS-05 // VM-METRICS
Telemetry Scale	Chunk / Partition Interval	Server DDR5 RAM	Retained Disk Footprint	Matched Infrastructure Tier
250K Active Series • 10K/s	`Daily MergeTree`	8 GB DDR5	120 GB Gen4 NVMe (1 yr)	Hostinger KVM 2 ($5.99/mo)
1M Active Series • 50K/s	`Daily + Monthly Parts`	16–32 GB DDR5	400 GB Gen4 NVMe (1 yr)	Hostinger KVM 8 ($19.99/mo)
5M Active Series • 150K/s	`Tiered Merge Parts`	64 GB DDR5	1.8 TB NVMe / ZFS (1 yr)	UltaHost VDS 64GB / InterServer
15M+ Series • 500K/s (5 yr)	`Cluster vmstorage`	128 GB DDR5	12 TB ZFS Archive	InterServer Bare-Metal Ryzen

Footprints derived deterministically via TimescaleOps tuple math; public vendor pricing retrieved 2026-11-12 from official vendor pages (`https://www.hostinger.com/vps-hosting`, `https://www.vultr.com/pricing/`, `https://ultahost.com/vds-hosting`, `https://www.interserver.net/vps/`, `https://chemicloud.com/wordpress-hosting`) — verify promotional and renewal terms at checkout.

Docker Compose — Single-Node VictoriaMetrics 12-Month Retention Configuration

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.106.0
    container_name: tso-victoriametrics
    restart: unless-stopped
    ports:
      - "127.0.0.1:8428:8428"
    volumes:
      - /var/lib/victoriametrics:/storage
    command:
      - "--storageDataPath=/storage"
      - "--retentionPeriod=12"
      - "--memory.allowedPercent=65"
      - "--dedup.minScrapeInterval=15s"
      - "--search.maxUniqueTimeseries=2000000"

1. Why Active Series Churn Dominates VictoriaMetrics and Prometheus RAM Sizing

Memory consumption in metric TSDBs scales primarily with active unique label sets rather than raw samples per second. Injecting ephemeral pod UUIDs or request IDs into metric labels multiplies inverted index entries every deployment cycle; inspect /api/v1/status/tsdb before provisioning larger VPS tiers.

2. Splitting Workloads Between VictoriaMetrics Counters and TimescaleDB Hypertables

We recommend routing pure numeric host and Kubernetes scrape counters into VictoriaMetrics while keeping Industrial IoT and financial telemetry that must JOIN against relational tenant, asset, or maintenance tables inside PostgreSQL 16 + TimescaleDB.

3. Deduplicating Dual-HA Prometheus Collectors in VictoriaMetrics Saves 50% Disk

When two redundant Prometheus or vmagent scrapers forward identical targets via remote_write, setting --dedup.minScrapeInterval equal to your scrape interval drops duplicate points automatically during background block merges.

TimescaleOps Engineering Q&A: TS-05 // VM-METRICS Hypertable Operations

Can Grafana query VictoriaMetrics using unmodified Prometheus PromQL dashboards?

Yes. VictoriaMetrics implements the Prometheus HTTP query API on port 8428, allowing existing node_exporter and Kubernetes dashboards to run without rewriting queries.

How much DDR5 RAM should we budget per 1 million active series in VictoriaMetrics on TimescaleOps?

Budget 8 GB to 12 GB of system RAM per 1 million active time series under moderate daily label churn so index caches and concurrent MetricsQL rollups avoid disk thrashing.

Does VictoriaMetrics require Gen4 NVMe or can multi-terabyte archives use ZFS pools?

Because LSM-tree merges convert random scrapes into sequential block writes, VictoriaMetrics runs efficiently on both Gen4 NVMe KVM instances and multi-terabyte InterServer ZFS pools.