What is VictoriaMetrics?
VictoriaMetrics is high-performance resource-efficient time series database with the following features:
- It ideally integrates with Prometheus + Grafana stack.
- It is easy to configure and operate.
- It requires less resources — RAM, CPU, I/O and disk storage — comparing to competitors. A single-node VictoriaMetrics may substitute moderately sized cluster built with competing solutions.
- It supports PromQL — Prometheus’ query language, which allows writing shorter and clearer queries for typical time series data comparing to SQL, InfluxQL or Flux. Additionally, it extends PromQL with useful features.
- It supports back-filling — i.e. ingesting historical data.
- It may handle high number of unique time series aka high cardinality.
VictoriaMetrics accepts time series data via widely used protocols:
- Prometheus remote write API — VictoriaMetrics perfectly works as a long-term remote storage for Prometheus, since this was the initial goal.
- Influx line protocol — VictoriaMetrics may replace InfluxDB without the need to switch from Telegraf or other Influx-compatible collectors.
- Graphite plaintext protocol with tags support over TCP and UDP.
- OpenTSDB put protocol over TCP and UDP.
Other protocols for data ingestion and querying may be easily added in the future thanks to the modular architecture.
Which versions were open-sourced?
The following versions were open sourced:
- Single-node version. It is easy to configure and operate, since it consists of a single binary with minimal configuration. It is fast, has good data compression and close-to-perfect vertical scalability. It easily handles millions of unique time series aka high cardinality.
- Cluster version. It scales horizontally to multiple nodes for really high volumes of time series data when the most beefy single node isn’t enough. For instance, metrics from billions of IoT devices, automotive industry or industrial sensors. The cluster version has simple architecture featuring high availability, good scalability, low operational overhead and low network bandwidth usage. It is optimized for running in Cloud such as Google Compute Engine.
We all prefer open source software. Our customers were constantly asking us “why didn’t you open VicotiraMetrics source code yet?” and “when do you plan to open sources?”. We believe that open-sourcing will help VictoriaMetrics gaining traction, so it will become prominent player in the world of time series databases.
Increased popularity should help us increasing revenue stream from commercial offerings:
- Paid support.
- Managed Cloud and SaaS versions. Tired of routine operations for on-premise VictoriaMetrics — backups, replication, capacity planning, regular updates, monitoring, security, etc.? Then welcome to managed Cloud or SaaS :)
Which drawbacks does VictoriaMetrics have?
- It doesn’t support SQL. Only PromQL.
- It is written in boring Go, not in zero-cost-abstracted Rust or in C++, which could be learnt in 21 days.
- It is free from magic, fancy abstractions and smart algorithms — just plain Go code.
- It is written from scratch and isn’t based on ancient reliable piece of code.
The future development for single-node and cluster versions of VictoriaMetrics will take place in the public repository. Third-party pull requests, feature requests and bug reports are welcome.
Just go to https://github.com/VictoriaMetrics/VictoriaMetrics and try it!
Read our articles in order to understand better design decisions across the code.
Update: comment the announcement on Hacker News.