If you have ever opened an end-of-month cloud SaaS invoice and felt your stomach drop upon seeing a six-figure bill from Datadog, you are in familiar company across the modern technology landscape. Datadog is an exceptional observability platform—its pre-built dashboards, unified tracing, and APM capabilities are undeniably slick. But Datadog has engineered what is arguably the single most predatory billing trap in enterprise cloud computing: Custom Metric Cardinality Pricing.

Here is how the trap works: your engineering team adds a seemingly innocent label to an application metric—for example, tracking request latency by tagging user_id, tenant_id, or order_id. In a high-traffic production application, that single line of code suddenly multiplies across thousands of customers. Overnight, your custom metric explodes from 100 time-series to 2,000,000 distinct time-series. At Datadog’s standard rate of $5.00 per 100 custom metrics per month ($0.05 per metric), that single accidental deployment generates a shocking $100,000 surprise charge on your next invoice.

Faced with runaway APM bills, forward-thinking infrastructure and FinOps leaders are repatriating their metrics to high-performance open-source time-series engines—led by VictoriaMetrics. Operating on a fraction of the hardware required by Prometheus or Datadog, VictoriaMetrics can ingest millions of high-cardinality metric samples per second on a single bare-metal server, reducing annual observability spend from $350,000+ down to less than $15,000. Let us conduct a forensic breakdown of Datadog’s cardinality billing math and architect an unshakeable VictoriaMetrics replacement.

How Much Can You Save Replacing Datadog with VictoriaMetrics?

The core mathematical conflict between Datadog and high-scale engineering lies in Combinatorial Cardinality Explosion. Cardinality is defined as the total number of unique time-series generated by multiplying every unique combination of label keys and label values. Consider this standard HTTP latency metric:

If your application has:

• 5 HTTP methods (GET, POST, PUT, DELETE, PATCH)
• 40 API endpoints
• 8 HTTP status codes (200, 201, 400, 401, 403, 404, 500, 502)
• 10,000 active customer IDs

The total time-series generated is: 5 × 40 × 8 × 10,000 = 16,000,000 unique metric streams.

At Datadog’s billing rate of $0.05 per metric, that single metric costs $800,000 per month. In Datadog, your engineers are forced to actively cripple observability—stripping away essential debugging labels to avoid bankrupting the company.

VictoriaMetrics was designed from the ground up to eliminate this fear. Written in highly optimized Go with custom zero-allocation memory buffers, VictoriaMetrics stores time-series data using a specialized MergeTree-like architecture. It compresses timestamps into fractional bits using delta-of-delta encoding and compresses values using XOR floating-point algorithms, reducing disk usage to just 0.7 bytes per data point. You can ingest hundreds of millions of high-cardinality metrics without incurring incremental billing penalties.

Under the Hood: VictoriaMetrics Columnar Compression & MergeTree Storage

To understand how VictoriaMetrics ingests millions of time-series on modest hardware where Prometheus runs out of memory and Datadog runs up six-figure invoices, one must examine its storage engine architecture. VictoriaMetrics rejects traditional row-oriented database storage in favor of an append-only, columnar MergeTree-inspired architecture specifically tailored for immutable time-series metrics.

When incoming metric samples arrive via HTTP or Prometheus Remote Write, they are buffered in high-speed memory buffers. Every second, buffered samples are sorted by metric name, labels, and timestamps, and written to disk as small, immutable columnar parts. In the background, continuous compaction routines merge smaller parts into larger consolidated blocks, applying double-delta encoding on timestamps and XOR floating-point compression on numerical values. This architecture delivers three profound engineering advantages:

• Zero In-Memory Index Lock-In: Standard Prometheus maintains an in-memory inverted index (head chunk) of all active time-series. When cardinality explodes to 10 million series, Prometheus crashes with Out-Of-Memory (OOM) errors. VictoriaMetrics writes indexes directly to disk using sparse bloom filters, keeping RAM usage completely flat and predictable.
• Extreme Columnar Compression: Real-world production benchmarks demonstrate that VictoriaMetrics compresses production metric streams into just 0.4 to 1.2 bytes per sample. Storing 100 million metric points requires only 70MB of disk space, allowing multi-terabyte metric histories to reside entirely on affordable local NVMe drives.
• Decoupled Multi-Tier Storage: In enterprise deployments, VictoriaMetrics supports transparent tiered storage: storing the last 30 days of metrics on ultra-fast local PCIe Gen5 NVMe for sub-second dashboard rendering, while automatically offloading older historical metrics to self-hosted Ceph object storage or MinIO for multi-year compliance retention at zero marginal cost.

Active Cardinality Triage with vmagent and PromQL

Even with VictoriaMetrics’s immense compression capabilities, engineering best practices require visibility into which services are generating runaway metric streams. VictoriaMetrics exposes a powerful TSDB status API (/api/v1/status/tsdb) that identifies the top 10 label names and values with the highest cardinality across your entire fleet in real time. If a developer accidentally introduces a high-cardinality tag (such as a UUID), platform engineers can use VictoriaMetrics’s lightweight ingestion proxy (vmagent) to drop or rewrite the offending label at line rate using regular expressions before it is written to storage.

Forensic Comparison: Datadog SaaS vs. VictoriaMetrics Bare Metal

Review the economic and architectural breakdown between Datadog custom metric billing and a self-hosted VictoriaMetrics cluster handling 10 million active metric series:

Bare-Metal Migration & Production Rollout Checklist

To safely decouple high-cardinality metrics from Datadog and deploy VictoriaMetrics today, execute this verified four-step sequence:

1. Deploy an In-Cluster Vector Ingestion Agent: Deploy Vector (by Datadog / open-source) or the OpenTelemetry Collector across your Kubernetes clusters. Configure Vector to scrape existing application Prometheus endpoints, acting as a high-throughput routing layer.
2. Implement Dual-Routing in Vector: Configure Vector to split incoming metrics. Route standard low-cardinality host metrics (CPU, RAM, disk) to Datadog, while simultaneously routing all high-cardinality application metrics (customer IDs, transaction IDs, order latencies) via Prometheus Remote Write to VictoriaMetrics:

   [sinks.victoriametrics]
   type = "prometheus_remote_write"
   inputs = ["scrape_high_cardinality"]
   endpoint = "http://victoriametrics.internal:8428/api/v1/write"

3. Deploy VictoriaMetrics Single-Node or Cluster Mode: For environments with under 20 million active series, deploy VictoriaMetrics Single-Node on a bare-metal server (AMD EPYC 16-core, 64GB RAM, 2x 1.92TB NVMe RAID-1). Single-node VictoriaMetrics handles up to 1 million samples per second with zero clustering complexity.
4. Connect Grafana Dashboards via PromQL: In Grafana, add VictoriaMetrics as a standard Prometheus data source (URL: http://victoriametrics:8428/prometheus). Import your existing Grafana dashboards. Your developers instantly gain access to high-cardinality debugging views with sub-second queries, while your Datadog bill drops by 90% next month.

Frequently Asked Questions: VictoriaMetrics vs. Datadog

Does VictoriaMetrics require managing complex Cassandra or Elasticsearch backends?

No. Unlike older time-series platforms like KairosDB or OpenTSDB, VictoriaMetrics requires zero external database dependencies. Single-node VictoriaMetrics is a single, self-contained static binary that writes directly to local NVMe storage or block devices. Cluster mode separates components into stateless ingestion proxies (vminsert), stateless query engines (vmselect), and dedicated storage nodes (vmstorage), eliminating the maintenance headaches of external storage clusters.

Can VictoriaMetrics run as a drop-in replacement for Prometheus?

Yes. VictoriaMetrics implements full 100% API compatibility with the Prometheus Remote Write API, Prometheus Query API, and PromQL. Furthermore, VictoriaMetrics includes MetricsQL—an extended dialect that improves upon PromQL by adding sub-queries, windowing functions, and mathematical transforms that make debugging complex distributed systems easier for platform teams.

Can VictoriaMetrics handle multi-tenancy and data isolation across teams?

Yes. VictoriaMetrics Cluster mode features native, built-in multi-tenancy. Every tenant is assigned a distinct numerical Account ID and Project ID embedded directly in the ingestion and query URL paths (e.g., /insert/0/prometheus/api/v1/write and /select/0/prometheus/api/v1/query). Data across different tenants is stored in completely isolated directories on disk with zero cross-tenant query visibility, allowing enterprise platform teams to securely host dozens of independent engineering organizations on a single shared physical cluster.

How does alerting work in VictoriaMetrics without Datadog Monitors?

VictoriaMetrics includes a dedicated, highly optimized alerting and recording rule evaluation component called vmalert. vmalert executes standard PromQL or MetricsQL alerting rules against VictoriaMetrics at configured evaluation intervals. When an alert condition fires, vmalert delivers the alert directly to standard Prometheus Alertmanager, which routes notifications to PagerDuty, Opsgenie, Slack, or webhook endpoints. Teams transition their existing alerting infrastructure seamlessly with zero dependency on proprietary SaaS alerting platforms.

How does VictoriaMetrics compare to Thanos or Cortex/Mimir?

Thanos and Mimir are powerful architectures, but they require substantial operational overhead: configuring object storage sync, managing compaction daemons, and balancing memory caches. In production benchmarks, VictoriaMetrics uses up to 7x less RAM and 4x less CPU than Thanos or Mimir when handling identical metric write volumes, making it vastly cheaper and easier to operate on owned bare metal.