VictoriaMetrics is a time series database (TSDB) written in Go. It's Prometheus-compatible out of the box, it speaks PromQL (with extensions via MetricsQL), accepts remote write natively, and ships as a single binary you run with CLI flags. You can deploy it as one node, and when you outgrow that, scale to a cluster without switching binaries or running a migration.

Why Is It So Much Cheaper?

There are a few concrete technical reasons the numbers look the way they do.

Custom Compression

VictoriaMetrics uses its own compression scheme for time series data. Across the public case studies, the average datapoint size on disk is consistently between 0.4 and 1.75 bytes. ARNES (the Slovenian research network) reports 0.4 bytes per datapoint. Adsterra reports 0.75 bytes. For context, a raw 64-bit float timestamp plus a 64-bit float value is 16 bytes.

The New York Times: One Topic for All Content Since 1850

The New York Times uses Kafka end-to-end to publish its content. Without any extra database in the system, all articles going back to the 1850s are stored chronologically in a single topic.

Materialized views and KTables are exposed using Kafka Streams. Because there are different schemas, different teams, and different data formats, they didn't build any separate API or microservice layer just for publishing. All services consume their data and assets directly from Kafka; what they do with that data afterwards and where they store it is up to them.

When a new article or piece of content is published, it's pushed to that same topic in Kafka and becomes accessible to every service at the same time.

Figure 1: The new New York Times log/Kafka-based publishing architecture.