Prometheus vs VictoriaMetrics

Prometheus is queried with PromQL, and VictoriaMetrics accepts both PromQL and its own MetricsQL language, so most existing dashboards and alert rules can be pointed at VictoriaMetrics without rewriting. The compatibility check is still required. Before switching, export every alerting and recording rule, run each expression against the same data in a staging copy, and compare results over a window that includes known incidents. Pay particular attention to rate and increase windows, staleness handling, histogram quantile functions and any query that uses a MetricsQL-only function, since those will fail on plain Prometheus. Confirm the exact behavior with the VictoriaMetrics documentation and your own rule set rather than assuming parity.

On the ingestion side, Prometheus accepts metrics from exporters through its HTTP pull model and can receive remote write from other agents. VictoriaMetrics accepts Prometheus exporters and remote write as well, and adds InfluxDB line protocol, Graphite, OpenTSDB, DataDog agent, New Relic agent and OpenTelemetry metrics, as listed in the VictoriaMetrics README. The extra protocols matter only if you already run agents or applications that emit them, or if you plan to consolidate several monitoring sources into one store. If every source already speaks Prometheus exposition or remote write, these additional endpoints add configuration surface without adding value, and you should keep the ingestion path as simple as possible.

Make the ingestion inventory a written deliverable before the pilot. List each source, its protocol, its scrape or push interval, and the labels it emits, then confirm that the chosen VictoriaMetrics build accepts each one in your environment. Check label names and series counts on the receiving side, because a change in how labels are normalized can silently split a series and break an alert. Ask the vendor or your implementation partner to document the exact endpoint and version each source uses, and keep a rollback path that keeps Prometheus writing until the dashboards and alerts agree.

Series count and retention drive disk and memory more than anything else you configure. Prometheus keeps its local time series database in two-hour blocks with a write-ahead log, and its default retention is 15 days, configurable by time or size through the retention flags. Disk grows with the number of samples retained, and the number of active series in the head block sets much of the memory footprint. VictoriaMetrics uses its own storage engine, so the same series count will not produce the same disk or RAM numbers in both systems. The practical step is to measure your current active series and ingestion rate in Prometheus, then ask each vendor or your own test lab to project the figures for your retention target. Do not carry numbers from one system over to the other.

Cardinality is the risk to plan for, and VictoriaMetrics gives you more controls to contain it. Each new combination of label values creates a new series, so a label such as a request ID or user ID can multiply storage and memory cost without anyone noticing. VictoriaMetrics documents relabeling and a cardinality limiter, which you configure through its command-line flags and can use to drop or limit unwanted labels before data is stored. Prometheus also supports relabeling in its scrape and remote write configuration, so the decision is where to enforce it and who owns the rules. Confirm the exact limiter behavior and flag names against the VictoriaMetrics README and release notes for the version you deploy, because limit semantics change between releases.

Reliability is valued over precision in Prometheus, so neither system should be your source for exact per-request billing. The Prometheus overview states that it is not a good choice where 100% accuracy is required, and the same design goals apply when metrics are sent to a long-term store. If you need exact per-request accounting, record those events in a transactional or event pipeline and reconcile it against metrics. Before go-live, run a load test with your own series counts, label sets, scrape intervals and query patterns. Include a failure test that restarts the storage node and measures the gap in data. Ask any implementation partner to deliver the test plan and results as part of the written scope.

Projects run long when the team treats the migration as a storage swap. Prometheus and VictoriaMetrics both ingest the same kinds of metrics, but the work around them is where the calendar moves. For a Prometheus-first estate, the first unknown is sizing: active series count, samples per second and the retention window you want. VictoriaMetrics single-node is a single binary configured through command-line flags, so the install itself is quick, but the storage volume, memory and CPU must be sized from your own cardinality, not from a default. Ask for a sizing run against a real sample of your series before anyone commits to a disk layout, and plan a second pass once the first week of ingestion has shown the true series count.

Query and alert validation is the most common source of overrun. PromQL and MetricsQL overlap, but not every expression, function or edge case behaves the same way, so dashboards and alert rules that were never reviewed will break quietly or return different values. Inventory every Grafana panel and every alerting rule, classify them by how much they matter, and compare results side by side over a agreed period before cutover. Undocumented scrape configurations are the other common surprise: relabeling rules, service discovery jobs and exporters added by hand years ago often exist only on one Prometheus server. The client should provide the current configuration files, a list of owners for each job, and access to the alert routing used by Alertmanager.

Retention, access and backups need decisions before build, not after. Prometheus defaults to 15 days of local retention, so teams often discover late that long-term storage needs an explicit policy for each metric family, and that some tiers may be Enterprise-only features such as multiple retentions or downsampling. Confirm which features your chosen edition includes, because that decision changes both the licensing conversation and the operating model. Access control must be mapped from existing Grafana roles and reverse proxy rules, and backup and restore must be tested, not just scheduled. The client should supply the retention requirements from compliance owners, an identity integration path and a restore test window agreed in writing with DeployOpen as part of a fixed scope.