InfluxDB

What is InfluxDB?

InfluxDB stores data whose primary key is time: metrics, sensor readings, market ticks — millions of timestamped points per second, queried by time window (“p95 latency per service, 5-minute buckets, last 24h”). Its storage engine (TSM, an LSM-tree variant) exploits time-series regularity: delta-encoded timestamps and compressed values reach ~1–3 bytes per point, and time-ordered layout makes range scans that would hobble a B-tree row store essentially sequential reads.

Cardinality: the constraint that defines the tool

Every unique combination of tags (measurement + host + region + …) creates a series, and series metadata lives in memory. Tag by hostname across 10k hosts: fine. Tag by user ID, request ID, or container ID: millions of series, ballooning memory, and the classic InfluxDB incident — cardinality explosion. The design rule is absolute: tags hold bounded, queryable dimensions; unbounded identifiers go in fields or don’t come in at all. This same constraint shapes every TSDB (Prometheus included); InfluxDB just teaches it most memorably.

Lifecycle is built in — use it

Time-series value decays with age, and InfluxDB operationalizes that: retention policies expire raw data automatically; downsampling tasks roll 1-second points into 1-minute aggregates for long-term trends. Teams that skip this ship a storage bill that grows linearly forever for data nobody queries at full resolution past a week.

What people get wrong

• Using a TSDB as a general database — no joins worth using, no transactions; relational questions belong in Postgres-land.
• Ignoring the ecosystem decision: InfluxDB (push, SQL-ish/Flux) versus Prometheus (pull, PromQL, Kubernetes-native) is an architectural fork; mixed stacks pay double.
• Version drift — v1 (InfluxQL), v2 (Flux), and v3 (SQL/Arrow) differ substantially; tutorials rarely say which they assume.

Primary source: InfluxDB documentation — storage engine and schema design