VictoriaMetrics vs Prometheus: mijn standaard, en wanneer ik toch Prometheus kies

Voor een nieuwe monitoringstack op Kubernetes is VictoriaMetrics mijn standaard en is Prometheus de uitzondering die ik moet verantwoorden. Ik grijp ernaar omdat Prometheus high available maken betekent dat je replica-paren bijplaatst, daarna Thanos of Mimir, daarna object storage en compactie-workers, terwijl VictoriaMetrics me dezelfde high availability en lange retentie geeft met veel minder om te draaien. Even eerlijk vooraf: ik raad VictoriaMetrics aan de meeste van mijn klanten aan, dus lees dit als het pleidooi van een practitioner met redenen erbij, niet als een neutrale scorelijst.

TL;DR

• Mijn standaard voor een greenfield-stack is VictoriaMetrics: zuiniger met RAM en disk, simpeler high available te draaien en saai in productie zodra het er staat. Ik hou Prometheus aan waar een gezonde stack al draait, of waar een harde eis voor vendor-neutraliteit het binnenhaalt.
• De efficiëntiewinst is reëel en onafhankelijk bevestigd (Criteo, Prezi), niet alleen vendor-benchmarks. De exacte "7x"-multipliers zijn van VictoriaMetrics zelf; over de richting bestaat geen twijfel.
• Prometheus is uitstekende software en de de-facto standaard (CNCF-graduated, de standaard voor Kubernetes-monitoring). De zwakke plek is operatie op schaal: high availability en lange retentie zijn bolt-ons, en cardinaliteit kan het onderuithalen.
• VictoriaMetrics is geen 100% PromQL, en dat kan me niet meer schelen, want ik schrijf MetricsQL tegenwoordig native en vind het prettiger. Heb je strikte PromQL-overdraagbaarheid tussen backends nodig, dan is dat een terechte reden om te blijven.
• Single-vendor-risico is reëel, vraag het de gebruikers van MinIO. Maar de Apache 2.0-kern van VictoriaMetrics kent geen contributor license agreement, dus die kan niet teruggetrokken worden zoals bij de edities van MinIO, HashiCorp en Redis.

Inhoudsopgave

• Snel overzicht
• Waarom VictoriaMetrics mijn standaard is
• Hoe de storage engines verschillen
• De resourcecijfers, en waarom ik de meeste wantrouw
• Cardinaliteit: de muur waar Prometheus het eerst tegenaan loopt
• Langetermijnopslag: Thanos, Cortex, Mimir of VictoriaMetrics?
• PromQL vs MetricsQL: de taal die ik zelf prefereer
• Allebei draaien in productie
• Wat het echt kost
• Migreren zonder big-bang cutover
• Governance: een enkele leverancier
• Wanneer ik toch Prometheus kies

Snel overzicht

Waarom VictoriaMetrics mijn standaard is

Eén Prometheus op Kubernetes is makkelijk. Een veerkrachtige Prometheus niet, en dat gat is waarom VictoriaMetrics mijn startpunt is. Zodra je high availability nodig hebt draai je twee replica's die dezelfde targets scrapen, en zodra je een globaal overzicht of retentie van meer dan een paar weken wilt komen Thanos of Mimir erbij, plus object storage en compactie-workers. Elk onderdeel is er weer eentje om te draaien, te monitoren en waarvoor je 's nachts gepaged wordt. VictoriaMetrics geeft me high availability met -replicationFactor en jaren retentie met één flag, op veel minder bewegende delen, inclusief harde multi-tenant-isolatie als een klant dat nodig heeft.

Ik draai het cluster met de VictoriaMetrics Operator, en waar het past zet ik VictoriaLogs erbij en, waar het zijn plek verdient, VictoriaTraces, zodat metrics, logs en traces uit één samenhangende stack komen in plaats van drie losse.

Als ik klanten van Prometheus af heb gehaald, was de uitkomst telkens dezelfde die ik wil: saai. Dashboards bleven werken, alerting bleef werken, het RAM-gebruik daalde, en queries die weken aan data doorploegen komen meteen terug. Saai is het hoogste compliment dat ik een monitoringsysteem kan geven, want saai betekent dat niemand om 3 uur 's nachts wakker ligt om het opnieuw op te bouwen.

Hoe de storage engines verschillen

Prometheus houdt recente data in een head block in het geheugen, schrijft elke binnenkomende sample eerst naar een write-ahead log op disk en compacteert oudere data daarna naar onveranderlijke blocks van twee uur op lokale disk. Elke active series kost grofweg 3 tot 4 KB RAM in de head, en dat is het getal om te onthouden over Prometheus: een miljoen active series is al meerdere GB RAM vóór je ook maar één query hebt gedraaid. De standaard lokale retentie is 15 dagen, block-compactie geeft periodieke disk-I/O-pieken die je in je eigen node-metrics terugziet, en clustering of replicatie zit niet in de doos. (TSDB-interne werking)

VictoriaMetrics gebruikt een storage engine die qua opzet dichter bij ClickHouse' MergeTree ligt. Het cluster opschalen betekent nodes toevoegen; historische data wordt niet herverdeeld, alleen nieuwe writes spreiden naar de nieuwe nodes. Het ontwerp vermijdt de WAL-write-amplificatie en de grote compactie-pieken van Prometheus, en de compressie is strakker voor typische time series. Replicatie is één flag, -replicationFactor, op de insert-laag.

Twee dingen vooraf. Single-node en cluster VictoriaMetrics gebruiken verschillende on-disk-formaten, dus je kunt datafiles niet zomaar van het een naar het ander kopiëren als je single-node ontgroeit; daarvoor gebruik je vmctl. En de standaard -retentionPeriod is één maand. Een issue uit september 2025 vroeg om die default veiliger te maken, omdat nieuwe gebruikers na 30 dagen stilletjes data kwijtraken; de maintainers sloten het als "not planned". Ik zet de retentie samen met de klant op basis van de opslag die ze hebben, dus mij heeft het nooit geraakt, maar zet hem meteen op dag één.

De resourcecijfers, en waarom ik de meeste wantrouw

VictoriaMetrics is zuiniger met RAM en disk. De richting van die claim geloof ik, want ik zie het op echte klantsystemen. De exacte multipliers wantrouw ik, en jij zou dat ook moeten doen, want bijna elke gepubliceerde benchmark komt van VictoriaMetrics zelf of van de oprichters.

Het veelgenoemde "7x minder disk, 5x minder RAM" stamt uit een benchmark uit 2020 van VictoriaMetrics' CTO op Prometheus v2.22, inmiddels jaren verouderd. Een recentere vendor-benchmark uit 2024 meldt 2,5x minder disk en 1,7x minder RAM. Zie je wat er gebeurt: het gat krimpt naarmate Prometheus beter wordt. Ga dus naar de onafhankelijke bronnen.

Het zuiverste neutrale datapunt is de engineering-blog van Criteo: bij ongeveer een miljard active series over 1.500 Prometheus-instances haalde VictoriaMetrics in productie zo'n één byte per datapoint, en daarmee kon Criteo zijn backend terugbrengen van 226 compute- en 156 storage-nodes naar 15 compute en 46 storage, terwijl het 15 keer zoveel data bewaart. Prezi, opgetekend door InfoQ met een SRE on record, heeft 5 miljoen active series van Prometheus af gehaald en zag 70% minder storage, 60% minder geheugen, 30% minder CPU en zware queries die van ruim 30 seconden naar 3 tot 7 seconden zakten. Dat zijn echte teams met echte cijfers, en ze wijzen dezelfde kant op als ik in mijn eigen migraties zie. Mijn eigen bewijs is de kwalitatieve versie: het RAM-gebruik zakt en het systeem wordt saai.

Het loopt niet voor iedereen één kant op, en de omvang hangt af van je workload en je versies. Prometheus heeft een deel van het gat ook gedicht met eigen verbeteringen sinds die oudere benchmarks draaiden. Eerlijke conclusie: het compressie- en RAM-voordeel van VictoriaMetrics is reëel, maar een volledig onafhankelijke, reproduceerbare benchmark op actuele releases van allebei bestaat nog steeds niet.

Cardinaliteit: de muur waar Prometheus het eerst tegenaan loopt

Cardinaliteit is de faal die de meeste mensen van Prometheus af duwt, en het is de moeite waard om precies te zijn over waarom. Elke unieke labelcombinatie is een aparte series, elke active series leeft in de head block en die head block leeft in RAM. Hang er een ongebonden label aan, een user ID, een request ID, een pod-naam die elke paar minuten verandert, en het aantal series explodeert. Prometheus zakt hier niet netjes terug; het loopt uit zijn geheugen en het proces gaat dood. Een ingebouwde harde cap op het aantal series is er niet. (cardinaliteit uitgelegd)

Dit is niet theoretisch, en het treft grote, capabele teams. Cloudflare draait 916 Prometheus-instances over 4,9 miljard series en moest eigen patches schrijven (een globale series-limiet, nette degradatie bij de sample-limiet) omdat upstream het geheugen niet kon afkappen zoals zij nodig hadden. PingCAP draaide een Prometheus-box op een instance met 96 cores en 768 GB die alsnog OOM ging, met een WAL-replay van ruim 40 minuten bij elke crash. Het cloudplatform van het Britse Ministry of Justice raakte 3 uur en 21 minuten zijn monitoring kwijt in april 2024, toen een WAL-replay na een herstart voorbij de startup probe van 15 minuten schoot en in een restart-loop belandde. Een herstart van Prometheus is niet gratis zodra de WAL groot is, en dat is precies wat het Ministry of Justice trof.

VictoriaMetrics gaat anders met dezelfde druk om. Als de in-memory series-cache vol loopt, leiden nieuwe series tot "slow inserts", index-werk op de achtergrond, in plaats van een directe OOM. De flag -search.maxUniqueTimeseries begrenst hoeveel series één query mag raken, zit gewoon in de gratis Apache 2.0-build, en er is een ingebouwde cardinality explorer om het label te vinden dat je pijn doet. Je houdt vm_slow_row_inserts_total in de gaten: kruipt die boven zo'n 5% van je inserts voor tien minuten, dan passen je active series niet meer in de cache en is het tijd om RAM bij te zetten of cardinaliteit te snoeien. Dat is een knop die je kunt aflezen en draaien, in plaats van een OOM-kill die je achteraf ontdekt. Die faal vanaf dag één vermijden, in plaats van wachten tot je erop knalt, is een groot deel van waarom ik op VictoriaMetrics begin.

Langetermijnopslag: Thanos, Cortex, Mimir of VictoriaMetrics?

De bolt-on-tax voor langetermijnopslag is een grote reden dat VictoriaMetrics mijn standaard is. Wil je dat Prometheus meer data langer bewaart met een globaal overzicht, dan hoef je de Prometheus-wereld niet te verlaten, maar je moet hem wel zelf in elkaar zetten, en de staat van elke optie telt mee.

• Thanos is CNCF Incubating, zet een sidecar naast elke Prometheus om blocks van twee uur naar S3-achtige object storage te sturen, en dedupliceert replica's tijdens de query met --query.replica-label. Het zit nog op 0.x-versienummers, wat niets zegt over de volwassenheid; het draait al jaren op grote schaal.
• Cortex wordt nog steeds onderhouden, met regelmatige releases, actieve community calls en een roadmap op KubeCon EU 2025. Voor nieuwe deployments is Mimir wel het aangeraden pad geworden.
• Grafana Mimir is de fork en doorontwikkeling van Cortex door Grafana Labs, open source sinds 2022, met v3.0 in november 2025 en een Kafka-gebaseerd write-pad. Het draait de metrics-backend van Grafana Cloud, dus het krijgt investering naar rato van de omzet van Grafana Labs. Tussen Cortex en Mimir kies ik voor een nieuwe opzet Mimir.

Stuk voor stuk capabele systemen. Het zijn er ook meer om te draaien dan het ene ding waar ze op geplakt zitten. Thanos, Cortex en Mimir houden je op PromQL met Prometheus als scrape-bron, in ruil voor het beheren van object storage, compactie-workers en rule-synchronisatie. VictoriaMetrics geeft me lange retentie met lokale compressie en veel minder onderdelen in één stack. De cijfers van Criteo hierboven kwamen juist uit het vervangen van een Thanos- en Cortex-evaluatie, en Prezi koos VictoriaMetrics boven allebei omdat block storage goedkoper en sneller was dan de S3-gebaseerde alternatieven voor hun workload. Als de vraag is "hoe maak ik Prometheus duurzaam en langlevend", beantwoordt VictoriaMetrics die met minder machinerie.

PromQL vs MetricsQL: de taal die ik zelf prefereer

MetricsQL, de querytaal van VictoriaMetrics, is een superset van PromQL. De overgrote meerderheid van bestaande PromQL-queries en Grafana-dashboards draait ongewijzigd, en daarom breken migraties geen dashboards. Maar ik schrijf geen PromQL meer uit gewoonte; ik schrijf MetricsQL uit keuze. Het voegt WITH-templates voor herbruikbare fragmenten toe, meerdere or-labelfilters in één selector, een keep_metric_names-modifier, eenheidssuffixen als Ki/Gi in queries, en rollup-functies die Prometheus mist zoals outlier_iqr_over_time en range_linear_regression. Heb je die eenmaal, dan voelt kale PromQL krap.

Wees wel helder over de ruil. MetricsQL wijkt bewust af van PromQL, en de onafhankelijke PromLabs-compliance-suite, gedraaid door Prometheus-medebedenker Julius Volz, zette VictoriaMetrics in de laatste gepubliceerde ronde op 74%, tegenover 100% voor Thanos en Cortex. De meeste afwijkingen zijn opzettelijk: MetricsQL houdt de metric name na functies als min_over_time() waar Prometheus die wegstript, laat rate() en increase() naar de sample vlak vóór het venster kijken, haalt NaN uit de output en lijnt timestamps uit op de resolution step. Verschillende daarvan vind ik correcter, en in de praktijk hebben de afwijkingen me nooit iets gekost. Maar er is één geval waar ze je wel iets kosten: heb je strikte PromQL-overdraagbaarheid tussen meerdere backends nodig, of beheer je een grote bibliotheek recording rules die op het exacte gedrag van Prometheus is afgesteld, dan worden de verbeteringen van MetricsQL een blok aan je been in plaats van een feature. Dat is een van de weinige redenen waarom ik een team op Prometheus zou houden.

Allebei draaien in productie

Benchmarks dekken ingest- en querysnelheid. De verschillen die je op dag twee voelt zitten ergens anders: failover, de collector, de Kubernetes-integratie en alert-state.

High availability

Prometheus heeft geen leader election. Het standaardpatroon voor HA is twee identieke instances die dezelfde targets scrapen met een onderscheidend replica-external-label, plus een Alertmanager-cluster dat silences en notificatiestatus via gossip deelt en alerts dedupliceert door zijn sends te spreiden (standaard --cluster.peer-timeout=15s). Geen van beide instances dedupliceert de data van de ander; dat lossen Thanos Query, de HA-tracker van Mimir of VictoriaMetrics op. VictoriaMetrics doet het met -replicationFactor=N op vminsert om elke sample naar N storage-nodes te schrijven, en -dedup.minScrapeInterval op vmselect om de duplicaten weg te halen die twee vmagent-instances maken als ze allebei dezelfde targets scrapen. Eén operationele noot: als een vmstorage-node uitvalt, herverdeelt vminsert zijn last over de overlevers, en op schaal kan die piek doorslaan in een OOM op de overgebleven nodes. Houd dus marge.

De collector-laag

Prometheus heeft sinds v2.32 een agent mode (--agent): alleen scrapen en remote-write, geen lokale TSDB, geen queries, met een WAL-buffer van ongeveer twee uur als de remote endpoint plat ligt. vmagent doet meer. Het buffert naar disk per bestemming (-remoteWrite.maxDiskUsagePerURL), zodat een storing langer dan twee uur je niet stilletjes data kost zoals de WAL van Prometheus dat doet, en het kan bij ingestie al pre-aggregeren met stream aggregation (-streamAggr.config) om cardinaliteit te pletten voordat die ooit in storage belandt. Die laatste feature pakt de cardinaliteits-tax direct aan, en Prometheus heeft er geen equivalent voor.

Kubernetes-integratie

Dit is het thuisveld van Prometheus. De Prometheus Operator met zijn CRD's ServiceMonitor, PodMonitor, PrometheusRule en ScrapeConfig, gebundeld in de kube-prometheus-stack Helm-chart, is de meest beproefde Kubernetes-monitoringopzet die er is. Het goede nieuws voor een overstap is dat de VictoriaMetrics Operator ernaast kan draaien en die CRD's automatisch omzet: een ServiceMonitor wordt een VMServiceScrape, een PrometheusRule wordt een VMRule, non-destructief, zodat je geleidelijk migreert zonder elke scrape-definitie te herschrijven. Zo verhuis ik klanten zonder big-bang dag.

Alert-state

vmalert is bewust stateless. De alert-state leeft in het geheugen en reset bij een herstart, tenzij je -remoteWrite.url en -remoteRead.url aansluit zodat hij de series ALERTS en ALERTS_FOR_STATE bewaart en terugleest. Vergeet je dat, dan reset elke herstart je for:-timers. Prometheus houdt die state standaard in zijn lokale TSDB. Een klein ding dat mensen op dag één verrast.

Wat het echt kost

Ik host VictoriaMetrics zelf voor klanten, meestal in private clouds, dus de managed prijzen hieronder zijn context en niet mijn pad. Ze zijn toch het weten waard, want de billingmodellen laten precies zien wat je met zelf hosten omzeilt, en omdat de kostenvalkuil het billingmodel is waar je workload in terechtkomt, niet de tarievenkaart.

• Amazon Managed Service for Prometheus rekent per binnengekomen sample, getrapt van $0,90 per 10M samples tot $0,16 bij volume. Hoogfrequent scrapen doet hier pijn, want je scrape-rate verdubbelen verdubbelt je sample-aantal.
• Google Cloud Managed Service for Prometheus rekent ook per sample maar is de duurste van de hyperscalers op praktische schaal, grofweg 4x AWS voor dezelfde last, en downsamplet oudere data.
• Azure Monitor managed Prometheus zit op een vlakke $0,016 per miljoen samples met 18 maanden retentie inbegrepen, wat het de goedkoopste cloud-native optie op gematigde schaal maakt.
• Grafana Cloud rekent op active series ($6,50 per 1.000 op Pro boven een gratis tier van 10.000) maar met een data-points-per-minute-multiplier: scrape je op 15s in plaats van 60s, dan betaal je grofweg 4x, want de rekening is max(series, DPM/included).
• VictoriaMetrics Cloud gebruikt vaste compute-tiers, single-node vanaf zo'n $202 per maand voor 500K series, dus een cardinaliteitspiek verandert je rekening niet tot je het plafond van je tier doorbreekt.

Per-sample-billing straft scrapefrequentie; active-series-billing straft cardinaliteit; de formule van Grafana straft allebei. In een Kubernetes-cluster waar labels vanzelf woekeren, riskeert een slordig customer_id- of ongebonden path-label niet alleen een OOM, het kan een usage-geprijsde rekening op dezelfde hardware vertienvoudigen. Zelf hosten omzeilt dat volledig: je kost is de machine, niet de cardinaliteit. Het is hetzelfde patroon als in mijn gids over FinOps voor Kubernetes: de regel die de rekening laat ontploffen is zelden de capaciteit die je plande, maar het gebruik dat je niet zag aankomen.

Qua sizing vertellen de vuistregels het verhaal: reken op zo'n 1 GB RAM per miljoen active series voor VictoriaMetrics tegenover meerdere GB voor Prometheus, volgens VictoriaMetrics' eigen capaciteitsrichtlijn en de bekende head-block-rekensom van Prometheus. Op een private cloud waar ik voor elke node betaal, is dat verschil de rekening, en dat per replica.

Migreren zonder big-bang cutover

Je hoeft niet op dag één te kiezen. Het schoonste pad is dual-write: laat Prometheus precies scrapen zoals het nu doet en voeg VictoriaMetrics toe als remote_write-target.

# In je bestaande prometheus.yml
remote_write:
  - url: http://victoriametrics:8428/api/v1/write

Vanaf daar:

• Grafana: VictoriaMetrics spreekt de Prometheus HTTP API, dus de standaard Prometheus-datasource werkt ongewijzigd. Een optionele VictoriaMetrics-datasource-plugin ontsluit de MetricsQL-extra's.
• Scraping: vmagent is een drop-in voor de scrape-engine van Prometheus, accepteert dezelfde scrape_configs, gebruikt minder RAM en buffert naar disk als de backend niet bereikbaar is.
• Kubernetes: draai de VictoriaMetrics Operator naast de Prometheus Operator en laat hem je bestaande ServiceMonitor- en PrometheusRule-objecten automatisch omzetten.
• Alerting: vmalert leest dezelfde rule-YAML en hergebruikt je bestaande Alertmanager.
• Historische data: vmctl importeert Prometheus-TSDB-snapshots, in tijdgefilterde brokken als dat nodig is.

De valkuilen staan gedocumenteerd; lees ze voor je je vastlegt. Grafieken kunnen tijdens de overgang iets afwijkende waarden laten zien tussen vmagent en Prometheus; door de rate()/increase()-afwijking wil je je alert-drempels even nalopen; zet -retentionPeriod expliciet zodat je de default van één maand niet erft; en kies single-node of cluster vóór je historie migreert, want de on-disk-formaten zijn niet uitwisselbaar. Over de clustervraag: ik draai cluster VictoriaMetrics met de Operator en het is saai gebleven; er is een gedocumenteerd data-loss-venster bij rolling restarts van vmstorage in sommige versies, en ik houd het in de gaten, maar het heeft me niet geraakt. Single-node blijft het simpelste dat werkt, dus heeft een klant het cluster niet nodig, dan geef ik het ze niet.

Governance: een enkele leverancier

Op governance heeft Prometheus een structureel voordeel op VictoriaMetrics. Het is CNCF-graduated, het tweede project ooit dat de graduated-status bereikte, na Kubernetes. De governance is een multi-company-structuur met maintainers van Grafana Labs, Red Hat, G-Research, Polar Signals en onafhankelijken, en geen enkel bedrijf kan het herlicentiëren of kapen omdat de CNCF het handelsmerk houdt en de contributor-basis duizenden organisaties beslaat. VictoriaMetrics is daarentegen een product van één bedrijf, VictoriaMetrics, Inc., rond de 50 mensen en nog steeds bootstrapped zonder externe funding begin 2026.

Elke dependency die je adopteert is een gok op de mensen erachter, en die gok pakt soms slecht uit. MinIO is het schoolvoorbeeld waar iedereen naar grijpt: in mei 2025 haalde het de admin-console (IAM, bucketbeheer, LDAP en OIDC) uit de community-editie en zette die in de betaalde tier, in oktober 2025 stopte het met het publiceren van community Docker-images en binaries, en eind 2025 ging het open source-project in maintenance mode. Dat is het risico, in levenden lijve.

VictoriaMetrics is een veiligere gok dan MinIO was, en de reden is structureel. MinIO kon zijn community-editie uitkleden omdat het via een contributor license agreement het copyright in handen had. VictoriaMetrics vraagt geen CLA, dus contributors houden hun eigen copyright en het bedrijf kan de bestaande Apache 2.0-code niet herlicentiëren, zelfs al zou het willen, precies de structurele bescherming die HashiCorp en Redis misten toen ze overgingen op de BSL in 2023 en een source-available licentie in 2024. De realistische druk is geen rug-pull op de open kern, maar nieuwe features die in Enterprise belanden, en dat is het in de gaten houden waard. Ik behandel VictoriaMetrics zoals ik Traefik of NGINX behandel: open source-infrastructuur waar ik met open ogen op leun, en een brug die ik oversteek als ik er ooit kom. (De governance-nasleep van die BSL-overstap heb ik uitgewerkt in mijn vergelijking van OpenTofu en Terraform.)

Nog een praktische noot: beide projecten gaan ervan uit dat je ze achter een firewall draait, niet open op het internet. De 336.000 internet-facing Prometheus-endpoints die Aqua Security in december 2024 vond, met lekkende credentials en API-keys, zijn een deployment-fout en geen ontwerpfout, maar wel een herinnering om dat ook echt te doen.

Wanneer ik toch Prometheus kies

Voor een greenfield-stack is mijn antwoord VictoriaMetrics. Prometheus heeft nog steeds een plek, dus hier zijn de gevallen waarin ik het laat staan of er bewust naar grijp.

De duidelijkste is de saaie: een Prometheus-stack die al schoon draait. Er is geen prijs voor het migreren van een gezond, stabiel systeem, en een migratie die je niet nodig had is een vorm van verspilling op zich. Draait het zonder pijn, dan laat ik het precies staan waar het staat, en dat zou ik jou ook aanraden.

Daarnaast houden twee redenen stand. De eerste is een harde eis voor vendor-neutrale, CNCF-governed tooling, het soort dat sommige inkoop- en compliance-regimes letterlijk voorschrijven; dat is een vakje dat VictoriaMetrics niet kan aanvinken en Prometheus wel. De tweede is strikte PromQL-overdraagbaarheid: een team dat meerdere metrics-backends draait, of op een dikke bibliotheek recording rules zit die op het exacte rate()- en metric-name-gedrag van Prometheus is afgesteld, merkt dat de bewuste afwijkingen van MetricsQL meer kosten dan de efficiëntie van VictoriaMetrics oplevert. Buiten die gevallen is het, voor iets nieuws, VictoriaMetrics, en van die standaard heb ik nog geen spijt gehad.