InfluxDB

What is InfluxDB?

InfluxDB stores timestamped measurements with tags and fields, and queries them with Flux or InfluxQL. It is a common destination for collectors that want somewhere better than a filesystem for high-frequency numeric data.

Best for

Storing high-frequency numeric data from sensors and systems

Why choose InfluxDB

InfluxDB was built for timestamped numeric data, and that shows in its data model: a measurement, a set of tags you can filter and group by, and fields that hold the actual values. Writing thousands of points per second is the normal case rather than the stress case, and downsampling — rolling raw data into hourly or daily aggregates — is a first-class feature rather than something you build yourself. It has native clients in most languages, a line protocol that is trivial to emit from a script, and a query language designed for the shapes you actually ask of sensor data: rates, means, percentiles and windows.

Replaces

• Prometheus
• TimescaleDB
• VictoriaMetrics

Key features

• Purpose-built time-series storage and compression
• Downsampling and retention policies
• Flux and InfluxQL query languages
• Telegraf collectors for almost anything

What to watch out for

InfluxDB has gone through major version changes that reshaped the product, and the differences between 1.x, 2.x and 3.x are substantial enough that tutorials you find may not apply to your install. The query language changed between versions too, so Flux and InfluxQL are not interchangeable and community answers frequently assume the wrong one. Cardinality is the classic failure mode: a tag with many unique values, like a device serial number, causes memory growth that is hard to diagnose after the fact. The open-source licensing and feature split with the commercial editions has also shifted over time, so check what applies to the version you are installing.

How to deploy

• Docker with a persistent data volume
• Create buckets and tokens via the UI
• Define retention before data grows

Getting started

Pick the major version deliberately and read that version's documentation rather than the most popular search result, because the APIs differ. Set retention policies or buckets with finite durations from the start, so old high-frequency data ages out automatically instead of filling the disk. Keep tags to low-cardinality dimensions — measurement, location, device type — and put unique identifiers in fields. Write a downsampling task early once you know which aggregates you query, so long-range dashboards do not scan raw data. Back up the data directory as part of your normal routine, since restoring a time-series database is not a copy-and-paste exercise.

Typical setup

A single service with a persistent data directory, written to by collectors running next to whatever produces the data. Buckets or retention policies are created with finite durations before the first write, so high-frequency data ages out on its own. Tags are kept to low-cardinality dimensions and unique identifiers go into fields. A downsampling task rolls raw points into hourly and daily aggregates for long-range charts, and dashboards query those rather than the raw stream. The data directory is backed up on the same schedule as everything else, and someone owns the decision to stay on one major version rather than upgrading casually.

Who should look elsewhere

If your data is infrastructure metrics and you already run Prometheus, adding InfluxDB means a second ecosystem for no gain — send it to a Prometheus-compatible store instead. Do not choose it if your values are mostly text or irregular JSON, because the model is numeric and timestamped by design. And if you cannot commit to reading version-specific documentation and keeping the install on one major version, the churn between releases will be a constant source of avoidable breakage.

Project health

• GitHub stars: 31,759
• Last code push: 2026-10-01
• Open issues: 2,167
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.