InfluxDB

InfluxDB is the most-deployed open-source time-series database. Designed by InfluxData (founded 2013), it is purpose-built for high-cardinality timestamped data — metrics, IoT telemetry, application traces, financial ticks, sensor readings — that arrives in heavy write streams and is queried mostly by time range plus tag filters.

1. Key Features:

Time-Series-Native Storage. Time-Structured Merge Tree (TSM) is an LSM variant tuned for timestamped, tag-indexed data. Compresses dramatically (10–100×) compared to row stores.
Tag-Based Indexing. Series are identified by measurement + tags + field. Tag-indexed queries are fast; high-cardinality unbounded tags are the classic pitfall.
Flux + InfluxQL. Flux is a functional, pipeline-style language designed for time-series transformations; InfluxQL is the older SQL-like dialect.
Continuous Queries / Tasks. Server-side scheduled aggregations (e.g. 1-min → 5-min downsampling) for retention and dashboard speed.
Retention Policies. Auto-drop data older than N days; pair with downsampling to keep summaries forever, raw data for a window.
Telegraf Ecosystem. 200+ input plugins for collecting from system metrics, databases, message brokers, cloud APIs.
InfluxDB 3.0 (IOx). Newer version rebuilt in Rust on Apache Arrow / Parquet / DataFusion; columnar columnar storage, SQL-first, designed to remove the high-cardinality limitation.

2. InfluxDB vs. Other Time-Series DBs:

InfluxDB. Purpose-built TSDB, broad ecosystem, separate from your RDBMS. Eventual cardinality issues in older versions.
TimescaleDB. Postgres extension — full SQL, joins to relational data, but a proper RDBMS engine underneath.
Prometheus. Pull-based monitoring TSDB; tightly coupled with metric scraping and alerting; not for raw event ingestion at scale.
VictoriaMetrics. Prometheus-compatible drop-in with much higher per-node density and lower memory footprint.

3. Use Cases:

System and application metrics — CPU, memory, request rates, error counts.
IoT and industrial telemetry at thousands of sensors per device.
DevOps observability dashboards (Grafana + InfluxDB / Prometheus is the canonical stack).
Financial market data — tick storage with downsampling for analytics.

4. Data model

InfluxDB stores points. Each point has a measurement name (similar to a table), a set of tags (string key-value pairs that are indexed and identify the source), one or more fields (the actual measured values: floats, integers, strings or booleans, not indexed), and a timestamp. All points sharing a measurement and an identical tag set form a series. Queries filter and group on tags and aggregate fields over time windows.

The key design rule follows from this: put things you filter or group by in tags, and put things you measure in fields. The number of distinct series, called cardinality, is what drives memory and index size, so tags must have bounded value sets.

5. Write and query path

Data arrives as line protocol, a compact text format, usually from Telegraf (InfluxData's collection agent with several hundred input plugins) or from client libraries. Writes go to a write-ahead log and an in-memory buffer, then are persisted in compressed columnar form; timestamps compress extremely well with delta encoding, and repeated values with run-length encoding. Retention policies (or bucket retention periods) drop data older than a configured age automatically, and downsampling jobs roll raw data up into coarser aggregates for long-term storage.

The product has gone through three storage generations. 1.x used the TSM engine with InfluxQL. 2.x kept TSM and introduced buckets, tokens and the Flux language. 3.x is a rewrite in Rust on Apache Arrow, DataFusion and Parquet, uses SQL and InfluxQL as query languages, and largely removes the cardinality limits of the earlier engine; Flux is not supported there. Check which version a tutorial targets before copying queries.

6. Worked example: write and query

# line protocol: measurement,tag=..,tag=.. field=..,field=.. timestamp
cpu,host=web1,region=us-west usage=63.2,idle=36.8 1727740800000000000
cpu,host=web2,region=us-west usage=21.7,idle=78.3 1727740800000000000

from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS

with InfluxDBClient(url="http://localhost:8086", token="TOKEN", org="acme") as c:
    w = c.write_api(write_options=SYNCHRONOUS)
    w.write(bucket="metrics",
            record=Point("cpu").tag("host", "web1").field("usage", 63.2))

-- InfluxQL (1.x, also 3.x): 5-minute average per host over the last hour
SELECT MEAN("usage") FROM "cpu"
WHERE time > now() - 1h
GROUP BY time(5m), "host";

-- SQL (3.x)
SELECT date_bin(INTERVAL '5 minutes', time) AS bucket, host, AVG(usage)
FROM cpu
WHERE time > now() - INTERVAL '1 hour'
GROUP BY bucket, host
ORDER BY bucket;

7. When to use InfluxDB versus alternatives

System	Choose when
InfluxDB	Push-based metrics and IoT/sensor data, built-in retention, Telegraf ecosystem
Prometheus	Pull-based Kubernetes and service monitoring with alerting rules
TimescaleDB	Time series that must join with relational data in PostgreSQL
Elasticsearch / OpenSearch	Logs and full-text search over events rather than numeric metrics
ClickHouse	General analytical SQL over very large event tables

8. Pitfalls

High-cardinality tags. Putting user IDs, request IDs or raw URLs in tags creates millions of series and exhausts memory on 1.x/2.x. Store them as fields.
Field type conflicts. Once a field is written as a float in a shard, writing an integer to it is rejected; write 63.0 rather than 63i consistently.
Duplicate points overwrite. Same measurement, tag set and timestamp means the new fields replace the old ones; use precise timestamps or an extra tag if events can coincide.
Timestamp precision. Line protocol defaults to nanoseconds; sending seconds without the precision parameter places data in 1970.