Insert benchmarks with inch: InfluxDB vs VictoriaMetrics

Recently VictoriaMetrics gained Influx line protocol support for time series’ data ingestion. It maps field names into metric names, while measurement names go to “measurement” label values. This streamlined apples-to-apples insert performance comparison for VictoriaMetrics and InfluxDB. The post exposes benchmark results for various number of unique time series (aka various cardinality), various number of points per insert request and various number of tags per point.

Benchmark tool

InfluxDB has a nice tool for measuring insert performance — influxdata/inch. This tool allows setting the following parameters among many others:

  • The number of tags and the number of distinct values for each tag.

These parameters can be tuned for simulating various real-world conditions such as the number of unique time series, the size of request sent to the server.


All the tests were run on the following hardware:

  • CPU: i7–7500U

InfluxDB version: 1.7.3. Docker image has been pulled from this repo.

VictoriaMetrics version: 1.6.2. Docker image has been pulled from this repo.

The number of concurrent clients: 4.

Total number of inserted values during each test: 30M.

The following time series cardinalities were tested: 1, 10, 100, 1K, 10K, 100K, 1M, 2M, 3M, 4M and 10M.

The following batch sizes were tested: 100, 1K and 10K.

The following number of fields were tested: 1 and 10.

The following number of tags were tested: 2 and 10.

Both client (influxdata/inch) and server (either VictoriaMetrics or InfluxDB) were run on the same hardware.

Benchmark results

Let’s start with 100 points per request (aka batch size: 100):

Image for post
Image for post

Noticeable things:

  • VictoriaMetrics outperforms InfluxDB on 1–2M cardinalities by 4x-5x.

Next, go to 1K points per request:

Image for post
Image for post

Noticeable things:

  • Insert performance increased with bigger batch size. VictoriaMetrics reached 1M points per second.

Let’s look at RAM usage for various cardinalities in order to understand why InfluxDB cannot finish 10M cardinality test on 16GB RAM:

Image for post
Image for post

As you can see, RAM requirements for VictoriaMetrics and InfluxDB are on par for low cardinalities up to 100K. After that InfluxDB RAM appetite skyrockets to 5GB for 1M unique time series and reaches 9GB for 4M unique time series. VictoriaMetrics uses 850MB RAM for 1M cardinality and 4GB for 10M cardinality. This means VictoriaMetrics may process 10x more distinct time series comparing to InfluxDB on the same amount of RAM.

Now go to batches with 10K points:

Image for post
Image for post

The performance increases a bit comparing to batches with 1K points.

All the previous tests were run on points with a single field. Let’s look at how performance scales with more fields.

Image for post
Image for post

10 fields per point lead to nice speedup — now VictoriaMetrics reaches 3.6M inserted values per second, while InfluxDB reached 1.5M inserted values per second.

Unfortunately, InfluxDB couldn’t fit more than 2M unique time series into 16GB RAM, so 3M, 4M and 10M cardinalities have no results for InfluxDB :(

And the last chart is for the increased number of per-point tags — from 2 to 10:

Image for post
Image for post

Increased number of tags means slower inserts for both VictoriaMetrics and InfluxDB. Additionally, InfluxDB couldn’t cram more than 1M unique time series with higher number of tags into available RAM.


  • VictoriaMetrics has better insert performance than InfluxDB in all the tests. The performance gap between VictoriaMetrics and InfluxDB increases with higher cardinality.

Raw benchmark results from this post are available in this spreadsheet. As for the select performance, see this spreadsheet. In short, VictoriaMetrics outperforms InfluxDB in all the queries, especially on heavy queries touching millions of data points and thousands of time series.

Though VictoriaMetrics’ main purpose is the best long-term remote storage for Prometheus, its’ single-server version still can substitute InfluxDB for collecting data from Influx-compatible agents such as Telegraf. VictoriaMetrics supports native PromQL, so simpler yet powerful queries could be used for building graphs from influx data comparing to InfluxQL or Flux.

Read this article for more details about VictoriaMetrics.

Update: VictoriaMetrics is open source now!

Written by

Founder and core developer at VictoriaMetrics

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store