VictoriaMetrics – high-performance, cost-effective and scalable time series database, long-term remote storage for Prometheus https://victoriametrics.com/
VictoriaMetrics on GitHub, writen in Go 🙂
Prominent features
- Supports Prometheus querying API, so it can be used as Prometheus drop-in replacement in Grafana. Additionally, VictoriaMetrics extends PromQL with opt-in useful features.
- High performance and good scalability for both inserts and selects. Outperforms InfluxDB and TimescaleDB by up to 20x.
- Uses 10x less RAM than InfluxDB when working with millions of unique time series (aka high cardinality).
- High data compression, so up to 70x more data points may be crammed into a limited storage comparing to TimescaleDB.
- Optimized for storage with high-latency IO and low iops (HDD and network storage in AWS, Google Cloud, Microsoft Azure, etc). See graphs from these benchmarks.
- A single-node VictoriaMetrics may substitute moderately sized clusters built with competing solutions such as Thanos, Uber M3, Cortex, InfluxDB or TimescaleDB. See vertical scalability benchmarks.
- Easy operation:
- VictoriaMetrics consists of a single executable without external dependencies.
- All the configuration is done via explicit command-line flags with reasonable defaults.
- All the data is stored in a single directory pointed by
-storageDataPath
flag. - Easy backups from instant snapshots.
- Storage is protected from corruption on unclean shutdown (i.e. hardware reset or
kill -9
) thanks to the storage architecture. - Supports metrics‘ ingestion and backfilling via the following protocols:
- Prometheus remote write API
- InfluxDB line protocol
- Graphite plaintext protocol with tags if
-graphiteListenAddr
is set. - OpenTSDB put message if
-opentsdbListenAddr
is set.
- Ideally works with big amounts of time series data from Kubernetes, IoT sensors, connected cars and industrial telemetry.
- Has open source cluster version.