If your monitoring bill is a line item you avoid reading, VictoriaMetrics is the project you have been hearing about. It is a time series database and monitoring platform, written in Go, that speaks PromQL, ingests from more than ten protocols, and ships as a single static binary with no external dependencies. At roughly 17,000 GitHub stars and shipping minor releases every two weeks, it is one of the most actively maintained entries in the observability space — and unlike several tools in this series, its community edition is Apache-2.0 and genuinely full-featured, not an open-core teaser.
The pitch is simple: VictoriaMetrics is the fast, cost-effective, scalable drop-in for Prometheus at the storage and query layer, plus a cluster mode for horizontal scale and sibling projects for logs and traces. Where Thanos, Cortex, and Grafana Mimir are stacks of microservices, VictoriaMetrics is (often) one executable. Same Grafana dashboards work unchanged because the query API speaks PromQL with MetricsQL extensions.
But "open source" and "free of strings" are two different claims, and this review separates them honestly. The community build is Apache-2.0 and open; the enterprise build adds anomaly detection, downsampling, mTLS, and managed LTS support under a commercial license. You can run a serious, multi-node, long-term metrics store on the free edition forever — but you should know exactly which features cross the paid line before you architect around an assumption. This article covers the architecture, the query language, the ingestion surface, the real cost of high cardinality, the backup story, the security defaults that changed in 2026, and how it compares to Prometheus, InfluxDB, and the microservice alternatives.
1. What VictoriaMetrics Actually Is
VictoriaMetrics is a time series database (TSDB) and monitoring solution. Its job is to store timestamped numerical samples — CPU percentages, request counts, latency histograms, queue depths — and answer range queries over them fast. If you run Prometheus, you already know the shape of the problem; VictoriaMetrics sits at the storage-and-query layer and either replaces Prometheus's local TSDB or acts as its long-term remote store.
The project is a family, not a single binary, though the single binary is the headline. There is VictoriaMetrics for metrics (using MetricsQL, a PromQL-compatible language), VictoriaLogs for logs (using LogsQL), and VictoriaTraces for traces (OTLP in, Jaeger and experimental Tempo APIs out), plus edge tools: vmagent (scraper and router), vmalert (alerting and recording rules), vmauth (auth proxy and router), and vmbackup/vmrestore (snapshot backups). Each is a separate Go binary with no external dependencies.
For an operator, the immediate value is consolidation. Instead of stitching Prometheus plus Thanos plus a log system plus a trace system, you can run the Victoria Stack — specialized single binaries that share the same insert/select/storage pattern. The governance caveat: this is a single-vendor project of VictoriaMetrics, Inc., not a CNCF foundation project, so the roadmap follows one company, albeit a bootstrapped one with a strong open-source commitment.
2. The Single-Binary Promise
The most underrated feature of VictoriaMetrics is that it is a single static Go binary with no external dependencies. There is no JVM, no sidecar, no object store you must stand up first, no ZooKeeper, no Kafka. You copy the binary, point it at a data directory, and it runs. This is radically simpler than the microservice TSDB alternatives and is the reason people describe it as "Prometheus without the operational tax."
The single-binary nature has real consequences. Upgrades are a binary swap, not a coordinated rollout of six services. Debugging is one process log, not a distributed trace across components. Resource behavior is easier to reason about because there is one thing consuming CPU and RAM. For a team that wants observability without hiring an observability team, this simplicity is the product.
The honest limit: "single binary" describes the single-node edition. The cluster edition is a set of binaries — vminsert, vmstorage, vmselect — that you must orchestrate. The simplicity claim is true at the node level and conditional at the cluster level, and conflating the two is the most common misconception new operators carry in.
3. Single-Node Versus Cluster
VictoriaMetrics ships in two deployment shapes. Single-node is one process handling ingestion, storage, and querying for sub-100-million-samples-per-second workloads — which covers the vast majority of organizations. It is the default you should reach for, and it scales surprisingly far on one machine because the storage engine is efficient.
Cluster mode splits the work across vminsert (ingest router), vmstorage (the data nodes), and vmselect (query nodes). This gives horizontal scale and availability: you can add storage nodes for capacity and select nodes for query throughput independently. The trade is operational complexity — you are now running and wiring three component types, managing their discovery and their failure modes.
The decision rule is straightforward: start single-node, measure, and only move to cluster when you hit a real ceiling (ingestion rate, storage capacity, or query concurrency) that one box cannot meet. Premature clustering is the fastest way to spend operational effort you did not need to spend. Most readers of this review will never need cluster mode, and saying so is the honest guidance.
4. MetricsQL: PromQL With Extra Knobs
VictoriaMetrics queries with PromQL, so every Grafana dashboard and every PromQL alert you already own keeps working. On top of PromQL it offers MetricsQL, a superset that adds functions and operators PromQL lacks — things like
lag, rate_over_sum, uniq, histogram_quantiles, and various aggregations that make certain queries expressible without pre-computation.
The practical upshot: compatibility is high but not 100 percent. Standard PromQL works unchanged; MetricsQL-specific syntax works only on VictoriaMetrics. If you write dashboards that lean on MetricsQL extensions, they will not port back to vanilla Prometheus without rewriting. For most teams this is a non-issue because they are migrating toward VictoriaMetrics, not straddling both — but if you run a hybrid, keep the dialect boundary explicit.
MetricsQL also exposes
with expressions for query templating and rollup functions for working with raw samples at different time resolutions. These are genuinely useful for high-cardinality or long-range queries and are a reason some teams prefer the engine once they learn the extensions. The cost is a small learning curve beyond plain PromQL.
5. The Ingestion Surface: Ten-Plus Protocols
One of VictoriaMetrics's strongest practical advantages is how many ways it accepts data. It ingests via Prometheus remote write and scraping, InfluxDB line protocol, Graphite, OpenTSDB, OpenTelemetry, Datadog, NewRelic, JSON lines, CSV, and a native format. That range means you can consolidate telemetry from several generations of tooling without running a translation layer for each.
For a shop with legacy Graphite metrics, newer OpenTelemetry traces-derived metrics, and a Datadog agent already deployed, VictoriaMetrics can absorb all three into one queryable store. This is the "unify the metrics" use case, and the broad protocol support is what makes it feasible without a fleet of exporters and bridges.
The implication for planning: your choice of ingestion protocol affects which client library or agent you deploy, and not every protocol carries the same fidelity. Prometheus remote write is the most common and best-supported path; the others are supported but vary in feature completeness. Validate the specific protocol your stack will use against the docs before you commit, rather than assuming feature parity across all ten.
6. Storage, Compression, and High Cardinality
The storage engine is where VictoriaMetrics earns its "cost-effective" reputation. It uses an inverted-index-plus-LSM design tuned for time series, with aggressive compression that routinely stores metrics at a fraction of the disk footprint Prometheus or some alternatives require. Lower storage cost translates directly into lower infrastructure cost over a multi-year retention window.
High cardinality — metrics with many unique label combinations, the classic killer of TSDB performance — is handled better than most. VictoriaMetrics's data structures and the cardinality limiter tool keep churny series manageable, which is why IoT fleets, APM trace-derived metrics, and financial tick data are cited use cases. It is not immune to cardinality explosions (nothing is), but it degrades more gracefully than naive stores.
The honest caveat: high cardinality is still a cost, not a free lunch. Every unique series consumes memory for indexing and disk for samples. The engine mitigates, but a metric with a user-ID or request-ID label will still balloon your store regardless of vendor. Use the cardinality limiter, relabel aggressively at ingest, and treat label design as a first-class architectural decision — VictoriaMetrics gives you better tools, not immunity.
7. The Apache-2.0 License: Community Is Genuinely Open
Here is the part that distinguishes VictoriaMetrics from several projects in this series. The community edition — both single-node and cluster — is licensed Apache-2.0, a permissive OSI-approved license. You can use it commercially, modify it, and never pay or publish anything. There is no open-core trap where the core is a teaser and the real product is paid.
This matters because the line between "open source" and "open source until you need the feature" has blurred across the industry. VictoriaMetrics draws a cleaner line: the database and its cluster mode are open, full stop. The enterprise features are additive conveniences (anomaly detection, downsampling, mTLS, vmgateway, managed LTS), not paywalled essentials. You can run a serious, multi-year, multi-node metrics platform on Apache-2.0 code alone.
The obligation Apache-2.0 asks is minimal: mostly attribution and a patent grant. For a self-hosted operator this is effectively invisible. If your organization bans copyleft licenses (AGPL, GPL), VictoriaMetrics's permissive license is a point in its favor versus the AGPL tools elsewhere in this series.
8. The Enterprise Line: What Crosses to Paid
Sovereignty requires naming the boundary, so here it is plainly. Enterprise and LTS releases add commercial features: anomaly detection (vmanomaly), downsampling and retention filters, mTLS, vmgateway, and long-term-support releases with extended maintenance. These are genuinely useful for large or regulated deployments, but they are not in the community Apache-2.0 build.
The practical read: if you need anomaly detection or downsampling, you either implement them yourself on the open build or buy enterprise. Neither is a trap; both are choices. The key is that the essentials — ingestion, storage, querying, clustering, alerting via vmalert, auth via vmauth — are all in the free edition. You are not forced into enterprise to get a working system, which is the distinction that matters.
For most readers, the free edition covers the job. Enterprise becomes relevant when you operate at scale or under compliance regimes that want vendor support and hardened features. Decide consciously rather than discovering the line mid-migration, and you will architect correctly from the start.
9. The Edge Tools: vmagent, vmalert, vmauth
Beyond the database, the Victoria Stack ships specialized tools that replace pieces of the Prometheus ecosystem. vmagent is a Prometheus-compatible scraper and metrics router: it supports 20-plus service-discovery types, relabeling, stream aggregation, and an on-disk queue per remote target, so it can sit in front of VictoriaMetrics and shape the firehose before it lands.
vmalert evaluates alerting and recording rules in MetricsQL (and LogsQL for logs), replacing Prometheus's alerting component and integrating with Alertmanager. vmauth is an HTTP auth proxy and router that adds basic/bearer/JWT auth with OIDC discovery and browser SSO, and routes queries across the three databases. vmbackup and vmrestore handle snapshot backups to S3, GCS, Azure, or a filesystem with incremental uploads.
The operational model: you compose the binaries you need. A common minimal production setup is vmagent scraping, VictoriaMetrics storing, vmalert alerting, and vmauth gating access — four small binaries instead of a microservice mesh. Each is independently upgradable and observable, which keeps the blast radius of any one component small.
10. VictoriaLogs and VictoriaTraces: The Full Stack
The reason people call it the Victoria Stack rather than just a database is the siblings. VictoriaLogs stores logs using LogsQL and ingests via Elasticsearch bulk, JSON lines, Loki push, OTLP, syslog, and journald. VictoriaTraces stores traces via OTLP (with Jaeger and experimental Tempo APIs) and was still pre-1.0 as of late 2026, so treat it as maturing rather than finished.
For a team tired of running Prometheus for metrics, Loki for logs, and Tempo/Jaeger for traces as three separate ecosystems, the Victoria Stack offers one vendor's coherent design language across all three signals. The query languages differ (MetricsQL, LogsQL, trace APIs) but the operational pattern — single binaries, no external deps, S3-backed snapshots — is consistent.
The honest status: metrics is the mature, GA product; logs is GA and solid; traces is younger and less battle-tested. Adopt metrics first, add logs when confident, and pilot traces cautiously. Claiming "one stack for everything" is accurate only if you weight the maturity of each component honestly, and traces is the one to watch rather than bet the farm on yet.
11. VictoriaMetrics Versus Prometheus
The natural comparison is the project it replaces. Prometheus is the default, ubiquitous, CNCF-graduated metrics system — and it has a local TSDB with known scaling limits: single-node, expensive long-term retention, and operational friction at high cardinality or long ranges. VictoriaMetrics is explicitly built to solve those: better compression, easier long-term storage, and graceful high-cardinality behavior.
The trade is ecosystem and familiarity. Prometheus has the deepest integration, the largest body of runbooks, and is what most exporters and tutorials assume. VictoriaMetrics is highly compatible but not identical, and some Prometheus-specific behaviors differ subtly. For a greenfield or a pain-driven migration, VictoriaMetrics wins on operability; for a happy, small Prometheus deployment, the switch is optional.
A common pattern is not to replace Prometheus entirely but to use VictoriaMetrics as the long-term remote store behind it, or to run vmagent in front and let VictoriaMetrics be the system of record while Prometheus handles scrapes. You do not have to choose all-or-nothing, and the gradual path reduces risk.
12. VictoriaMetrics Versus InfluxDB
InfluxDB (covered elsewhere in this series) is the other time series contender, and the contrast is instructive. InfluxDB v3 is a Rust rewrite with a Core (open, single-node, recent data) versus Enterprise (closed, HA, long history) split — a hard community-versus-commercial cut at the capability layer. VictoriaMetrics keeps clustering in the open Apache-2.0 build and only adds conveniences in enterprise.
Query language is the other divide. InfluxDB uses InfluxQL and SQL-ish dialects; VictoriaMetrics uses PromQL/MetricsQL. If your team already thinks in PromQL and lives in Grafana, VictoriaMetrics is the lower-friction fit. If you come from a SQL or InfluxQL background, InfluxDB's model may feel more natural, though VictoriaMetrics's ten-plus ingestion protocols include InfluxDB line protocol, softening the migration.
The sovereignty read: both let you own your data. The difference is where the paid wall sits. VictoriaMetrics's wall is farther out (clustering is free), which makes it the more permissive default for a self-hosted operator who might eventually need scale without a sales conversation.
13. Versus the Microservice Alternatives: Mimir, Thanos, Cortex
The microservice TSDB world — Grafana Mimir, Thanos, Cortex — solves Prometheus scaling with many components: queriers, store gateways, compacters, object storage backends. They scale to enormous sizes and are proven at the hyperscale end, but they demand object storage and a real operations practice. VictoriaMetrics cluster mode achieves similar horizontal scale with fewer moving parts.
The decision is about operational appetite. If you already run S3-class object storage and have a platform team, Mimir/Thanos are legitimate and hugely capable. If you want scale without standing up object storage and orchestrating a dozen services, VictoriaMetrics cluster is the lighter path to the same destination. Neither is wrong; they price operational complexity differently.
The single-binary edition is the clearest differentiator: no microservice TSDB gives you a one-process production store at the same scale envelope. That is why VictoriaMetrics is often the first recommendation for teams escaping Prometheus pain without wanting to become distributed-systems operators.
14. The Real Cost of Running It
Let us put numbers on ownership. Single-node VictoriaMetrics is famously light: it runs comfortably on a 2 vCPU / 4 GB RAM machine for modest workloads, and the binary itself is tens of megabytes. Storage is where the long-term cost lives, and VictoriaMetrics's compression keeps it lower than most — but retention math still applies: more metrics, finer intervals, longer history equals more disk.
The biggest cost lever is cardinality, not sample rate. A few well-designed metrics cost little; a metric with an unbounded label (user ID, request ID, URL with query string) can multiply your series count by millions and blow up RAM and disk regardless of vendor. Budget for relabeling and cardinality limits in your planning, because that is the line item that surprises people.
Compared to a hosted metrics service, self-hosting VictoriaMetrics on your own hardware is dramatically cheaper at scale — the cloud bill for high-volume metrics is precisely what drives teams to it. The counter-cost is you operating it: backups, upgrades, capacity planning. For a team already self-hosting, it slots into an existing habit; for a team new to ops, the software is free and the competence is the real price.
15. Where Your Data Goes (and Stays)
Data sovereignty is the quiet reason many operators choose VictoriaMetrics over a hosted metrics vendor. Your samples live in files on your own storage volume (or your own object bucket if you back up there). There is no SaaS telemetry pipeline, no "we use your metrics to improve our models" clause, no vendor holding your observability hostage to a renewal. The Apache-2.0 license guarantees the code cannot acquire such a clause without you seeing it.
The one place data can leave your control is the backup destination. If you snapshot to a cloud bucket (S3/GCS/Azure), your metrics reside there too — which is usually a deliberate, owned choice, not a leak. Keep backups on infrastructure you control (or a bucket under your own account) and the sovereignty story stays clean end to end.
For regulated environments, this self-contained model is a feature: metrics about your systems never traverse a third party's pipeline. The corollary is that security is now yours — encrypt at rest, restrict query access via vmauth, and monitor the metrics store itself, because it knows more about your infrastructure than almost anything else you run.
16. Backup and Snapshot Discipline
VictoriaMetrics backs up with vmbackup, which takes point-in-time snapshots and uploads incrementally to S3, GCS, Azure, or a filesystem. The incremental design keeps backup cheap after the first full copy, and vmrestore replays them. This is far less disruptive than an export/import cycle and is the supported production path.
The discipline that matters is testing the restore. A snapshot you have never restored is a hope. Periodically spin up a scratch instance, run vmrestore from your backup target, and confirm recent metrics appear. Because VictoriaMetrics stores data in its own format, a restore is a binary operation, not a re-ingest — fast when it works, and you should verify it works before you need it.
For single-node, also consider the data directory's disk: back it up or snapshot the volume at the hypervisor level as a complement to vmbackup. Defense in depth applies to your observability store especially, because when everything else is on fire, the metrics that tell you why are the system you most need intact.
17. High Cardinality: The Tax You Control
We have mentioned it twice because it is the single most common VictoriaMetrics failure mode. High cardinality happens when a metric's label set has many unique combinations — a
http_request_duration_seconds{user_id="..."} or path="/search?q=..."} explodes into millions of series. The store handles it better than most, but "better" is not "free."
The controls are at ingest. Use relabeling to drop or hash high-cardinality labels before they reach storage. Use stream aggregation in vmagent to pre-rollup chatty series. Use the built-in cardinality limiter to cap series per metric and surface offenders. None of these are VictoriaMetrics-specific wisdom; they are time series hygiene the engine makes easier to enforce.
The organizational lesson: label design is an architecture decision owned by the teams emitting metrics, not something the database fixes. Teach service owners to use bounded labels (status code, route template) instead of unbounded ones (user ID, raw URL). Do that, and VictoriaMetrics rewards you with cheap, fast queries; skip it, and no TSDB saves you.
18. The Multitenancy Default Flip of 2026
A security-relevant change shipped in 2026 that every operator should know: as of v1.150.0,
-enableMultitenancyViaHeaders defaults to true on vmagent, vminsert, and vmselect. Previously the default was false. This affects how the components interpret tenant headers and, if you ran with assumptions about the old default, can change isolation behavior on upgrade.
The operational implication is to read the changelog before upgrading across that boundary. If your setup relied on the old default, flipping the binary without adjusting config could alter multitenancy semantics in ways that surprise you — sometimes silently weakening isolation between tenants, sometimes breaking ingestion that expected the prior behavior.
This is a broader lesson across the Victoria Stack: releases are frequent (minor every two weeks) and occasionally carry security or default changes (v1.147 restricted delete-series endpoints to POST to prevent SSRF-based deletion; v1.149 flipped a rerouting default). Track the changelog; do not blindly bump the image tag in production.
19. LTS Lines and Upgrade Discipline
VictoriaMetrics maintains a current release line plus two supported LTS (long-term support) lines at any time, with a new LTS every six months and twelve months of support each. LTS releases are where conservative operators park: they get fixes without chasing every two-week minor. The current line plus LTS pairs (for example v1.148.x and v1.136.x in 2026) give you a stable target.
The upgrade discipline: pin a version, subscribe to release notes, and test upgrades in staging before production, especially across the security-default boundaries noted above. Because the single binary is easy to swap, the temptation is to always run latest — resist it for production. A known-good LTS with a tested restore is worth more than a shiny minor with an unread changelog.
The cluster edition amplifies this: upgrading vminsert, vmstorage, and vmselect should be coordinated and version-matched per the project's compatibility guidance, because mixed-version clusters can exhibit subtle query or routing inconsistencies. Single-node upgrades are trivial; cluster upgrades deserve a plan.
20. The Kubernetes Operator
For Kubernetes deployments, the VictoriaMetrics Operator manages the components as custom resources: VictoriaMetricsCluster, VictoriaMetricsSingle, and the agents, alerts, and scrapes around them. The operator handles deployment, scaling, and config from declarative manifests, which fits GitOps workflows and keeps your monitoring infra in version control.
The operator is mature and widely used, but it is another layer to understand. If you are already Kubernetes-native, it is the natural path and removes most of the manual wiring. If you are not, the docker-compose or binary path is simpler and the operator adds a learning curve you may not need for a single-node store.
The recommendation: match the deployment method to your existing practice. Kubernetes shops use the operator; everyone else uses the binary or compose. VictoriaMetrics does not force either, and that flexibility is part of its appeal — but do not adopt the operator merely because it exists; adopt it because your platform is Kubernetes.
21. Who Should Run VictoriaMetrics — and Who Should Not
Run VictoriaMetrics if you operate metrics at a scale or retention where Prometheus's local TSDB hurts, if your metrics bill is a line item you avoid reading, or if you want Prometheus compatibility without the microservice operational tax. Single-node covers most; cluster covers the rest. The Apache-2.0 license means no surprise paywall for the core.
Do not run it if you need a turnkey hosted service with zero ops — that is Datadog or Grafana Cloud, not self-hosting. Do not adopt cluster mode preemptively; single-node is the right start for nearly everyone. And do not treat VictoriaTraces as production-grade yet if traces are mission-critical; pilot it, do not bet on it.
The aggregate verdict is a strong yes for the right operator: a permissively licensed, efficiently stored, Prometheus-compatible metrics platform that scales from one binary to a cluster without changing vendors. Pair it with Grafana for dashboards (covered in this series) and CrowdSec or Authelia for the access layer, and your observability stops costing you sovereignty or a fortune.
22. Monitoring VictoriaMetrics Itself
You cannot watch your infrastructure with a tool you are not watching. VictoriaMetrics exposes its own metrics on the /metrics endpoint — ingestion rate, active series, disk usage, query latency, and more — and you should scrape those into itself or a separate store. The classic mistake is treating the metrics database as infallible; it is the first thing you lose visibility into when it is the thing failing.
Key signals to alert on: vm_rows_added_total (ingestion rate), vm_active_series (cardinality pressure), the gap between vm_free_disk_space_bytes and vm_data_size_bytes (capacity), and query-duration histograms. A spike in active series usually means a cardinality leak from a new unbounded label. A backed-up vmagent queue means downstream is slow or unreachable. Disk filling is the most common silent outage, so alert on it early.
The meta-lesson is observability of the observer. Run VictoriaMetrics so that the failure of one node still leaves you able to see the others — which is exactly why the cluster edition's separate insert, select, and storage roles help, and why even a single-node store should ship its own metrics somewhere redundant. A monitoring system that goes dark exactly when the rest of your infra does is not monitoring; it is a liability.
23. A Minimal Production Recipe
For most teams a sane starting point is: a single VictoriaMetrics binary on a machine with fast local disk, vmagent scraping your targets (or Prometheus remote-writing into it), vmalert evaluating rules, and vmauth in front if you expose queries beyond localhost. Backups via vmbackup to an S3 bucket you own on a daily cron, and Grafana pointed at the query endpoint. That is four small binaries and one bucket.
Concretely: give the store fast SSD, not slow network-attached disk — storage I/O is the dominant performance factor. Size RAM for the active-series index; a few GB covers most small deployments, while cardinality explosions are what break this assumption. Set retention explicitly; an unset value surprises people, and metrics are not kept forever by default. Keep the compose file in git and pin the image to an LTS tag.
Document the restore procedure next to the backup cron, because the two are one process and the second is the part everyone forgets. This recipe carries a small-to-mid organization through years of metrics without a dedicated platform team, and scales to cluster mode only when a measured ceiling demands it.
24. Security Hardening
A metrics store knows more about your infrastructure than almost anything else you run — every endpoint, every latency, every error rate. Treat its exposure accordingly. Do not bind the query port to the public internet. Put vmauth or a reverse proxy such as Caddy in front with authentication, and restrict who can query and who can write.
Use the built-in access controls: vmauth can enforce JWT or basic auth and route by tenant, and the enterprise build adds mTLS and vmgateway for a tighter posture, but the community edition is enough for most deployments behind a proxy. Encrypt the data directory at rest and encrypt the backups. Mind the 2026 security changes — the delete-series endpoints restricted to POST exist precisely to prevent SSRF-based data deletion, so staying current is a security control, not a chore.
The sovereignty point recurs: because the data never leaves your infrastructure, security is fully in your hands, which is freedom and responsibility at once. A metrics store with no auth on a public IP is not a monitoring system; it is a reconnaissance gift to attackers. Harden it like the crown jewel it is.
25. The Bottom Line
VictoriaMetrics is the rare monitoring project that is both permissively licensed and operationally light: a single Go binary you can run today, a cluster you can grow into, and a query language your Grafana dashboards already speak. The community edition is Apache-2.0 and full-featured — clustering included — with only conveniences behind the enterprise line. It ingests from more than ten protocols, compresses aggressively, and handles high cardinality more gracefully than the alternatives it replaces.
The honest caveats are operational, not licensing: cardinality is a tax you control through label design and relabeling; the 2026 multitenancy default flip means you must read changelogs before upgrading; the traces sibling is still maturing; and single-vendor governance means the roadmap follows one company. None of these undercut the core value. If your metrics live in a vendor's cloud and your bill shows it, VictoriaMetrics is the credible, sovereign, and frankly cheaper way home.
Start single-node, scrape what you have, set a retention you can afford, and point Grafana at it. Add vmagent, vmalert, and vmauth as the needs appear, back up with vmbackup from day one, and revisit cluster mode only when a number on a dashboard tells you to. That disciplined, incremental path is exactly what the single-binary design invites — and it is why VictoriaMetrics keeps winning teams back from both the metrics bill and the microservice maze. Pair it with the access and visualization layers elsewhere in this series, and your observability stops costing you either sovereignty or a fortune.
Related
For the rest of a sovereign, self-hosted stack, these pieces from our series travel with VictoriaMetrics:
- InfluxDB: The Rust Rewrite That Split Open and Closed — the other time series contender, and the contrast in where each project draws its paid line.
- Grafana: Dashboards Over Everything You Own — the visualization layer to hang your VictoriaMetrics queries on.
- CrowdSec: The MIT Security Engine That Watches Your Perimeter — the free IPS to put in front of your metrics endpoint.
- Authelia: SSO and 2FA for Everything Behind Your Reverse Proxy — the auth layer to gate vmauth and your dashboards.
- Caddy: The Web Server That Encrypts for You — the reverse proxy to publish the query API over TLS.
Comments (0)
No comments yet. Be the first to comment!