Skip to content
Navigation

Type at least two characters. Search covers page titles, headings, tags and database names.

↑ ↓ to navigateEnter to openEsc to close0 pages
Time Seriesintermediate

InfluxDB

Purpose-built time series database whose storage engine and query language have changed substantially across major versions.

2 min readIntermediateUpdated Edit this page

What it is

A time-series database designed for metrics, events and sensor data, with a self-contained stack including collection (Telegraf), storage, tasks and a UI. Licensing varies by component and version, spanning MIT, Apache-2.0 and commercial editions.

Architecture

Points are grouped into measurements, sharded by time, and stored with compression. Retention is enforced by dropping whole shards. Tasks perform scheduled downsampling into longer-retention buckets.

Best use cases

  • IoT and sensor telemetry where a self-contained collection-to-dashboard stack is valuable.
  • Application and infrastructure metrics, particularly with existing Telegraf deployments.
  • Deployments already standardised on InfluxDB with the operational knowledge in place.

When not to use it

  • When you need time-series data joined with relational data — TimescaleDB fits better.
  • When Prometheus compatibility is a requirement and PromQL is the language your teams know.
  • Where the availability model of the edition you can run does not meet your requirements — verify this before committing, as clustering has varied by version and edition.

Data model

Measurements containing points, each with a timestamp, tags (indexed strings, part of the series key) and fields (unindexed values). The tag/field distinction is the most consequential thing to get right: tags multiply cardinality, fields do not.

Consistency and transactions

No multi-point transactions. Writes are append-oriented, with last-write-wins semantics for identical timestamps and series.

Scaling model

Vertical scaling for the open-source distribution, with horizontal scaling in commercial offerings. Cardinality, not data volume, is usually the binding limit.

Replication

Varies substantially by version and edition. A common open-source arrangement is redundancy at the collection layer — agents writing to two independent instances — with deduplication at query time.

Backup and recovery

influx backup and influx restore, with the ability to restore a single bucket under a new name. Tokens, organisations, users and task definitions must be captured alongside the data.

Monitoring

Prometheus-format metrics at /metrics. Watch series cardinality per bucket, write and query rates and errors, task execution success, disk usage and memory — which tracks the index and therefore cardinality.

Common mistakes

Production checklist

See Time Series Production Checklist.