What is the main purpose of VictoriaMetrics?

To provide the best long-term remote storage solution for Prometheus.

Which features does VictoriaMetrics have?

Which clients do you target?

The following Prometheus users may be interested in VictoriaMetrics:

  • Users who don’t want to bother with Prometheus’ local storage operational burden - backups, replication, capacity planning, scalability, etc.
  • Users with multiple Prometheus instances who want performing arbitrary queries over all the metrics collected by their Prometheus instances (aka global querying view).
  • Users who want reducing costs for storing huge amounts of time series data.

How to start using VictoriaMetrics?

Start with single-node version. It is easy to configure and operate. It should fit the majority of use cases.

Is it safe to enable remote write storage in Prometheus?

Yes. Prometheus continues writing data to local storage after enabling remote storage write, so all the existing local storage data and new data is available for querying via Prometheus as usual.

How does VictoriaMetrics compare to other clustered TSDBs on top of Prometheus such as M3 from Uber, Thanos, Cortex, etc.?

VictoriaMetrics is simpler, faster, more cost-effective and it provides useful extensions for PromQL. The simplicity is twofold:

  • It is simpler to configure and operate. There is no need in configuring third-party sidecars or fighting with gossip protocol.
  • VictoriaMetrics has simpler architecture, which means less bugs and more useful features in a long run comparing to competing TSDBs.

See comparing Thanos to VictoriaMetrics cluster.

How does VictoriaMetrics compare to InfluxDB?

VictoriaMetrics requires 10x less RAM and it works faster. It is easier to configure and operate. It provides better query language than InfluxQL or Flux.

How does VictoriaMetrics compare to TimescaleDB?

TimescaleDB insists on using SQL as a query language. While SQL is more powerful than PromQL, this power is rarely required during typical TSDB usage. Real-world queries usually look clearer and simpler when written in PromQL than in SQL. Additionally, VictoriaMetrics requires up to 70x less storage space comparing to TimescaleDB for storing the same amount of time series data.

Does VictoriaMetrics use Prometheus technologies like other clustered TSDBs built on top of Prometheus such as M3 from Uber, Thanos, Cortex?

No. VictoriaMetrics core is written in Go from scratch by fasthttp author. The architecture is optimized for storing and querying large amounts of time series data with high cardinality. VictoriaMetrics storage uses certain ideas from ClickHouse. Special thanks to Alexey Milovidov.

Are there performance comparisons with other solutions?

Yes:

What is the pricing for VictoriaMetrics?

The following versions are open source and free:

We provide commercial support for both versions. Contact us for the pricing.

The following versions are commercial:

  • Managed cluster in the Cloud.
  • SaaS version.

Contact us for the pricing.

Why VictoriaMetrics doesn’t support Prometheus remote read API?

Remote read API requires transferring all the raw data for all the requested metrics over the given time range. For instance, if a query covers 1000 metrics with 10K values each, then the remote read API had to return 1000*10K=10M metric values to Prometheus. This is slow and expensive. Prometheus remote read API isn’t intended for querying foreign data aka global query view. See this issue for details.

So just query VictoriaMetrics directly via Prometheus Querying API or via Prometheus datasoruce in Grafana.

Does VictoriaMetrics deduplicate data from Prometheus instances scraping the same targets (aka HA pairs)?

Data from all the Prometheus instances is saved in VictoriaMetrics without deduplication.

The deduplication for Prometheus HA pair may be easily implemented on top of VictoriaMetrics with the following steps:

1) Run multiple VictoriaMetrics instances in multiple availability zones (datacenters). 2) Configure each Prometheus from each HA pair to write data to VictoriaMetrics in distinct availability zone. 3) Put Promxy in front of all the VictoriaMetrics instances. 4) Send queries to Promxy - it will deduplicate data from VictoriaMetrics instances behind it.

Where is the source code of VictoriaMetrics?

Source code for the following versions is available in the following places:

Does VictoriaMetrics fit for data from IoT sensors and industrial sensors?

VictoriaMetrics is able to handle data from hundreds of millions of IoT sensors and industrial sensors. It supports high cardinality data, perfectly scales up on a single node and scales horizontally to multiple nodes.

Where can I ask questions about VictoriaMetrics?

See VictoriaMetrics-users group.

Where can I file bugs and feature requests regarding VictoriaMetrics?

File bugs and feature requests here.

Are you looking for investors?

Yes. Mail us if you are interested in.