VictoriaMetrics single-node vs cluster version

Which VictoriaMetrics version fits your ingestion and tenancy needs

If you are choosing long-term storage for Prometheus or another metrics source, start with the single-node version unless tenancy, replication or ingestion scale rule it out. The VictoriaMetrics cluster documentation recommends the single-node version for ingestion rates below one million data points per second, and it says the single-node version is easier to configure and operate. That threshold is the first number to check against your own measurements, taken at peak rather than on an average day. If your workloads sit well under it and every team writes to one shared namespace, a single binary with command-line flags, run as one instance with a tested backup routine, is a credible production design and a much smaller thing to own.

Move to the cluster when one of three conditions appears. The first is multi-tenancy: the docs state that single-node VictoriaMetrics does not support it, while the cluster offers multiple independent namespaces for time series data. The second is replication. The cluster enables it with -replicationFactor=N on vminsert and needs at least 2*N-1 vmstorage nodes, so a replicated design means planning for those nodes from day one. The third is ingestion volume that would need more than one storage node, which the docs suggest is the point where the cluster starts to make sense. Ask your team to measure both ingestion rate and the number of distinct tenants before choosing, because either one can force the decision on its own.

Both versions are open source under the Apache License 2.0, so license does not separate them. The decision is mainly operational: the cluster splits work across vminsert, vmselect and vmstorage, and each role needs capacity, monitoring and upgrades. Before committing, confirm with the VictoriaMetrics maintainers or in the VictoriaMetrics cluster documentation how your chosen replication and backup approach behaves during node failure, since the docs say replication does not replace regular backups. Keeping the single-node option open is also a sound plan: its data can be moved into a cluster only through a process you must test, so pilot the migration path early.

Single-node and cluster side by side

This table compares the VictoriaMetrics single-node version (option A) with the cluster version (option B) across license, components, ingestion guidance, multi-tenancy, replication, operating effort, backups and Prometheus remote write fit. Read each row as the condition that decides the choice, and treat the question marks as items to confirm before you commit to a design.

Factor	Option A: single-node	Option B: cluster
License	Apache License 2.0, per the VictoriaMetrics README	Apache License 2.0, per the VictoriaMetrics README, so licensing does not separate the two options
Components	One binary with no dependencies, configured through command-line flags	Separate vminsert (accepts data), vmselect (runs queries) and vmstorage (stores raw data)
Ingestion guidance	Docs recommend single-node for ingestion below one million data points per second	Docs suggest the cluster when ingestion reaches or exceeds one million data points per second or fewer vmstorage nodes would be needed
Multi-tenancy	Not supported, according to the docs	Supported through independent namespaces for time series data
Replication and node count	No cluster replication; plan durability through storage and backups	Enabled with -replicationFactor=N on vminsert, requiring at least 2*N-1 vmstorage nodes
Operating effort	Docs describe it as easier to configure and operate than the cluster	Several components to size, upgrade and monitor; confirm the effort with the vendor for your topology
Backups	Backup automation is listed under VictoriaMetrics Enterprise; confirm which backup approach applies to your edition	Replication does not replace regular backups, according to the docs; confirm backup tooling for each vmstorage node
Prometheus remote write fit	Prometheus can send samples directly to a single endpoint through remote write	Prometheus remote write targets vminsert; confirm the exact endpoint and authentication setup with the vendor

How the one million points per second threshold should guide sizing

The VictoriaMetrics cluster documentation recommends the single-node version for ingestion rates lower than one million data points per second, and it describes the single-node version as easier to configure and operate. The same docs suggest the cluster when fewer vmstorage nodes would be needed. Treat that figure as a starting point for sizing, not a hard limit. The threshold says where the vendor expects the single-node design to stop being the simpler choice, but your hardware, sample sizes, series count and query pattern all shift where that point actually falls.

Before you choose, measure your own environment. Record the sustained ingest rate in data points per second, not just the peak during a scrape burst, along with the number of active time series, the rate at which new series appear, and the query load from dashboards, alerting rules and any remote readers. Confirm with your own tests how much memory and disk a single node needs to hold your retention window at that load, and whether a single host can absorb a restart or a disk failure within the maintenance window your operations team accepts. If the answer is that one host is comfortable, the single-node version usually leaves less to operate. If the math points to several vmstorage nodes, the cluster becomes the design to evaluate.

Ingestion rate alone does not settle the question. If you need multi-tenancy, which the docs describe as a cluster feature because single-node VictoriaMetrics does not support it, the cluster may be required even at a modest ingest rate. The same applies if you need replication: -replicationFactor=N on vminsert needs at least 2*N-1 vmstorage nodes, so a replicated design can require more storage nodes than your throughput alone would justify. Replication also does not replace regular backups, so plan backup automation separately. Ask the vendor or your own test lab to confirm how each option behaves at your projected load before you commit.

What the cluster adds: vminsert, vmselect and vmstorage

The cluster version splits VictoriaMetrics into three roles that scale separately, and each role adds something to run. The cards below cover what the single binary does, what each cluster component handles, and what the cluster adds in multi-tenancy and replication.

Single binary as the baseline

Single-node VictoriaMetrics runs as one small binary with no external dependencies, configured through command-line flags and distributed as binaries and Docker images. It handles ingestion, storage and queries in one process, so there is one service to upgrade, back up and monitor. Check whether your ingestion rate and query load fit on one host before you accept the extra moving parts of a cluster.

vmstorage holds the raw data

vmstorage is the cluster component that stores the raw time series data. Each vmstorage node holds its own share of the data, so capacity, disk I/O and retention planning all happen per storage node. Operators should size disks, plan backups for every vmstorage node, and confirm how node additions or removals rebalance data before going to production.

vminsert accepts ingested data

vminsert is the stateless entry point that accepts writes from Prometheus remote write, OpenTelemetry and other supported protocols, then distributes them across vmstorage nodes. It can be scaled out horizontally behind a load balancer to absorb more ingestion. Operators need to point every agent at the vminsert tier and monitor it separately from storage, since a failing ingestion tier silently stops data flow.

vmselect runs the queries

vmselect executes PromQL and MetricsQL queries by fetching data from the vmstorage nodes and merging the results. Dashboards and alerting rules hit this tier, so its capacity and query concurrency limits shape user experience. Operators should check that Grafana and alerting data sources point at vmselect endpoints and that query load is monitored independently from ingestion.

Multi-tenancy is cluster-only

Multi-tenancy, which provides separate namespaces for time series data, is a cluster feature. The docs state that single-node VictoriaMetrics does not support it, so teams that need isolated tenants for different business units, customers or environments must choose the cluster from the start. Confirm the tenant model, access control and how tenant identifiers flow through your agents before you design the topology.

Replication needs more storage nodes

Replication is enabled with -replicationFactor=N on vminsert and requires at least 2*N-1 vmstorage nodes. The docs say offloading replication to durable storage is more cost-effective and that replication does not replace regular backups. Plan the node count, disk footprint and backup schedule together, since a replicated cluster still loses data if backups are missing.

When replication and multi-tenancy justify the cluster

Replication is the first thing that pushes a VictoriaMetrics deployment toward the cluster version, and the node count grows faster than most teams expect. Replication is enabled with the -replicationFactor=N flag on vminsert, and the cluster docs require at least 2*N-1 vmstorage nodes for it. A replication factor of 2 therefore needs at least 3 vmstorage nodes, and a factor of 3 needs at least 5. Before you commit to a factor, confirm the node count, the disk and memory per vmstorage node, and the failure domains (zones, racks or hosts) you need to spread copies across. The docs also say that offloading replication to durable storage is the more cost-effective option, so compare the cost of extra vmstorage nodes with the cost of a storage layer that already provides durability.

Replication is not a backup. The cluster docs state that replication does not replace regular backups, because a bad delete, a faulty retention setting or a corrupted write is copied to every replica. Plan backups as a separate control with their own restore test, whichever version you run. Single-node deployments need the same discipline, but the cluster adds more components to back up and restore consistently, so ask your operator to document how vmstorage data, configuration and retention settings are captured and restored.

Multi-tenancy is the other justification, and it is a hard boundary rather than a tuning choice. The cluster version supports multiple independent namespaces for time series data, and the docs state that single-node VictoriaMetrics does not support multitenancy. If several teams, business units or customers must keep their metrics separate, or must be queried under separate access, the cluster is the only option in this family. If one organization with one monitoring team is the only user, a single-node instance with clear naming conventions may be enough. Confirm with your security and compliance leads whether tenant separation is a requirement or a preference before you size the cluster.

Which version fits which team situation

A single platform team running one Prometheus estate usually fits the single-node version. The VictoriaMetrics cluster docs recommend single-node for ingestion rates below a million data points per second, describe it as easier to configure and operate, and suggest it when fewer vmstorage nodes would be needed. The single binary is configured through command-line flags and ships as binaries and Docker images, so one team can own the whole setup.

Ingestion check: Measure your sustained rate of data points per second across all remote write and scrape sources before choosing, since the threshold is the docs' guidance and not a hard limit.
Remote write fit: Prometheus can send samples to VictoriaMetrics for long-term storage, and the single-node version accepts the same PromQL-compatible queries in Grafana.
Storage placement: The README says NFS-based storage such as Amazon EFS and Google Filestore is supported, which helps when the data path must stay in your own cloud account.
Where cluster is justified: If one platform team's ingestion grows past the threshold or needs more than one vmstorage node's capacity, the cluster version becomes the better fit.

Confirm the expected growth of series and samples over your planned retention period with your own load measurements before committing to one layout.

Upgrades, backups and skills for each version

This table compares how the single-node and cluster versions differ on upgrades, backups, monitoring, failure handling and team skills. Read it as a checklist of operating tasks: the more components and replicas you run, the more of these rows apply to you. The main takeaway is that the single-node version is the simpler system to operate, and the cluster's extra effort is justified mainly by ingestion scale, multi-tenancy or replication needs.

Operating area	Single-node VictoriaMetrics	Cluster VictoriaMetrics
Upgrade path	One binary and one data directory to upgrade, with the docs describing it as easier to configure and operate	Three component types (vminsert, vmselect, vmstorage) to upgrade in a coordinated order, and each must stay compatible with the others
Backup approach	Back up the single data directory; Enterprise adds backup automation	Back up every vmstorage node; replication is not a substitute for regular backups according to the docs
Replication and node counts	No built-in replication across nodes	Enabled with -replicationFactor=N on vminsert, needing at least 2*N-1 vmstorage nodes
Monitoring	Watch one process for resource use, disk space and ingestion health	Monitor each component type separately, plus traffic between vminsert, vmstorage and vmselect
Failure handling	A node outage stops ingestion and queries until the node recovers, so plan for restore time	Components can be lost within replication limits, but failed nodes still need repair and rebalancing
Long-term support	Confirm with the vendor which Enterprise LTS line covers your version and its end-of-support date	Same LTS question applies; confirm the cluster build and component versions are covered together
Evaluation	Enterprise and LTS releases can be evaluated with a free trial license per the README	Use the same free trial license to test cluster upgrades before production
Team skills needed	Basic Linux operations, flag-based configuration and Prometheus or Grafana integration	Distributed systems troubleshooting, capacity planning for storage nodes and network design between components

How to move from single-node to cluster without losing history

This sequence moves VictoriaMetrics from a single-node instance to the cluster version while keeping metric history available for queries throughout the switch. It runs both systems side by side, checks that results match, and retires the single node only after the cluster has been accepted. The exact history transfer method depends on the version in use and must be confirmed in the VictoriaMetrics documentation.

Measure current ingestion and series load
The platform or monitoring team records the current ingestion rate in data points per second, the active series count, the query load from dashboards and alert rules, and the retention period the business requires. It compares the ingestion rate with the threshold in the VictoriaMetrics cluster documentation, which recommends the single-node version for rates below one million data points per second. The step is done when the team holds a written baseline that shows whether the cluster is justified at all.
Decide tenancy and replication requirements
The architecture owner decides whether separate teams or customers need independent namespaces, because multi-tenancy is a cluster feature and the documentation states that single-node VictoriaMetrics does not support it. If replication is required, the owner notes that the replication factor set with -replicationFactor=N on vminsert needs at least 2*N-1 vmstorage nodes, and that replication does not replace regular backups. The step is done when node count, storage layout and backup plan are written down and approved by the team that owns the data.
Stand up the cluster in parallel
The platform engineer deploys vmstorage, vminsert and vmselect next to the existing single-node instance, using the configuration that matches the version in use from the VictoriaMetrics cluster docs. Storage for vmstorage is sized from the baseline, and each component is checked for network reachability and health before anything points at it. The step is done when the cluster accepts a test write and answers a test query, while no production dashboard or alert depends on it yet.
Send remote write to both systems
The engineer configures the Prometheus or agent remote write targets so that new samples reach the single-node instance and the cluster at the same time. The team confirms that both sides receive the same series labels and comparable sample counts over a window agreed in advance, and it investigates any gap it finds. The step is done when reconciliation checks show no unexplained differences and the team signs off on the results before validation continues.
Validate dashboards, alerts and queries
The monitoring team runs its critical dashboards and alert expressions against both systems and compares the results. Differences caused by rate windows, staleness handling or relabeling are investigated before cutover, and any cardinality limits configured on the cluster are checked against real series counts. The step is done when every critical panel and alert returns matching results or a documented difference that the owners have accepted.
Confirm the history transfer method
The engineer takes a verified backup of the single-node data first, then decides how existing history reaches the cluster, whether through a copy, export or import procedure. The method must be confirmed in the VictoriaMetrics documentation for the exact version in use, because dual-write only carries samples from the point it started. The step is done when a sample time range has been restored or imported into the cluster, queried successfully, and written up as a runbook.
Cut over queries to the cluster
The team points Grafana data sources, alerting and any remote read consumers at vmselect, and keeps the single node available in read-only mode for an agreed rollback period. Ingestion and query health on the cluster are watched closely during that period. The step is done when the rollback period closes without needing a rollback, and the cutover record names the owner who approved the change.
Retire the single-node instance and archive
After the cutover is accepted, the team stops writes to the single node, takes a final backup, archives it under the retention policy, and decommissions the host. Runbooks, backup jobs and the monitoring of the monitoring stack itself are updated to remove the old instance. The step is done when the single node is removed from every alerting target and a restore from the archive has been tested at least once.

Questions buyers ask before choosing or hiring help

How much more effort does the VictoriaMetrics cluster need than single-node?

The cluster needs noticeably more operating effort because it runs three separate roles: vmstorage holds the raw data, vminsert accepts ingested data, and vmselect runs queries. Each role has its own sizing, scaling, configuration and monitoring, and you must plan how they are deployed and upgraded together. The VictoriaMetrics cluster docs say the single-node version is easier to configure and operate than the cluster version. Effort grows further if you enable replication, because -replicationFactor=N on vminsert requires at least 2*N-1 vmstorage nodes. Ask any implementation partner to list every component, its failure modes and the runbooks they will write for each one.

Can a single-node VictoriaMetrics be upgraded to the cluster version later?

The supplied VictoriaMetrics facts do not describe an in-place conversion from single-node to cluster, so do not plan on one without confirming it. The practical path is usually to stand up the cluster and move data or traffic to it, and that migration needs a written plan for retention, dashboards, alert rules and remote write endpoints. Confirm the exact migration steps, data handling and rollback with VictoriaMetrics documentation before you commit. Because single-node does not support multitenancy, teams that expect to split tenants later should weigh that requirement at the start.

What must our team already know before running VictoriaMetrics?

Your team should understand Prometheus first, because VictoriaMetrics serves as long-term storage for Prometheus data and is queried with PromQL or MetricsQL. Knowledge of Grafana is needed to build and maintain dashboards against the data source. If you run the cluster on Kubernetes, your engineers also need working Kubernetes skills for scheduling, storage volumes, networking and upgrades. Some ingestion paths, such as remote write and OpenTelemetry metrics, also require someone who understands how the sending side is configured. Map these skills to named people before choosing the version.

Can our own team run VictoriaMetrics without outside help?

Many teams can run the single-node version with existing Prometheus and Grafana skills, since the README describes a single small binary configured through command-line flags. The cluster is a different decision: it adds several roles, storage nodes and replication planning, so it is a larger task for a small team. Be honest about on-call capacity, upgrade cadence and backup ownership. The VictoriaMetrics docs say replication does not replace regular backups, so someone must own that work. Outside help is usually a question of how many hours and skills you can staff, not whether the software is possible to run.

What drives the implementation cost of a VictoriaMetrics deployment?

Implementation cost comes from people, not from the open-source license, because the Apache License 2.0 applies to both versions. The main drivers are the number of components (single-node or vmstorage, vminsert and vmselect), the replication factor, the number of ingestion sources and their formats, the dashboards and alert rules to migrate, the storage platform, and the number of environments such as test and production. Recurring costs include infrastructure, storage, upgrades and on-call time. If you want Enterprise features such as backup automation or LTS release lines, those are separate licensing decisions that you should price with VictoriaMetrics. Ask any partner to split their quote into one-time build work and recurring operations.

What should we ask for in a written scope for VictoriaMetrics?

A written scope should name the version (single-node or cluster), the ingestion sources and protocols, the expected retention and storage platform, the replication factor and node count, and the tenancy model. It should list the Prometheus, Grafana and Alertmanager integrations in scope, the dashboards and alert rules to migrate, and the backup and restore approach. Ask for deliverables such as runbooks, upgrade procedures, monitoring of the VictoriaMetrics components themselves, and handover sessions. Confirm which items are one-time and which are retainers. DeployOpen works on fixed-scope engagements agreed in writing before work starts, so the scope document is where these decisions are recorded.

How should we decide between single-node and cluster when ingestion is growing?

Start from the ingestion rate. The VictoriaMetrics cluster docs recommend single-node for ingestion below one million data points per second and suggest the cluster when fewer vmstorage nodes would be needed. Measure your real rate across all sources, including peaks, and plan for growth in your decision. Also check whether you need multitenancy or replication, because those are cluster features. If you are near the threshold, ask a partner to model both options against your data and operating capacity in a written evaluation before choosing.

What to confirm with the vendor before you commit

The facts behind this comparison settle the broad split but not the details you need to size and sign off a deployment. Start with storage and node sizing. The cluster docs give a rough ingestion threshold of one million data points per second for choosing single-node, and the replication rule of -replicationFactor=N on vminsert needing at least 2*N-1 vmstorage nodes. Neither tells you how much disk, memory or CPU a given ingest rate and retention window will consume in your environment. Ask the vendor for sizing guidance tied to your expected series count, sample rate, retention and query load, and confirm it against the VictoriaMetrics cluster documentation before you buy hardware.

Next, confirm the upgrade and migration path. Ask whether data written to a single-node instance can be moved into a cluster, whether a cluster can be collapsed back to single-node, and which versions support each route. Because single-node VictoriaMetrics does not support multitenancy, a move to the cluster may also change how tenant namespaces and existing dashboards or Prometheus remote write targets are addressed. Get the procedure, its downtime and its rollback steps in writing, and ask who performs them, your team or the vendor.

Then clarify the licensing of Enterprise features. The README places anomaly detection, backup automation, multiple retentions, downsampling and LTS release lines in VictoriaMetrics Enterprise, and says those releases can be evaluated with a free trial license. Confirm which of these features you actually need, whether they apply to the single-node or cluster build or both, what the license terms are for production use, how a trial converts to a paid agreement, and whether the core team's support covers your version. Also confirm the current release line you will pin to, since VictoriaMetrics v1.154.0 was published on October 12, 2026 and releases arrive about every two weeks. Record the answers in a written quote or support statement, not a sales call summary.

How DeployOpen scopes and supports VictoriaMetrics deployments

DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside the client's own infrastructure, including VictoriaMetrics. We start by confirming the ingestion rate, tenancy needs and retention targets, then agree the single-node or cluster design in writing before any work begins.

How we scope

Measure current and expected ingestion rate in data points per second before choosing a topology.
Record tenant boundaries, retention needs and which Prometheus or Grafana clients will write and query.
Agree in writing whether the engagement is fixed-scope and which deliverables and environments are included.

How we build

Deploy the chosen layout in your cloud accounts, data center or air-gapped network, with storage sized for your retention.
For cluster designs, configure vminsert, vmselect and vmstorage separately and set replication only after confirming node counts.
Test failover, restore and query behavior against the agreed scope before handing the environment over.

How we hand over

Document the architecture, configuration flags, backup procedure and the reasons the single-node or cluster design was chosen.
Provide an operating runbook covering upgrades, scaling steps and what to monitor on each component.
Walk your operators through restores and scaling decisions so your team can run the platform independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan version upgrades against the release cadence and confirm whether Enterprise or LTS lines suit your needs.
Ask any provider, including DeployOpen, to confirm backup and replication responsibilities in the written scope.