InfluxDB

InfluxDB is a database built on one assumption: data is a stream of timestamped points, written constantly, and queried mostly over recent time windows and downsampled aggregates. That assumption drives the data model, the storage layout, and the deliberate absence of general transactions.

Version scope matters unusually much here. InfluxDB 3 shares a name with 2.x but little else: 1.x spoke InfluxQL, 2.x introduced Flux and the TSM engine, and 3.x was rebuilt on Apache Arrow, DataFusion, and Parquet with SQL (and a revived InfluxQL) as the query language. 2.x-era tutorials - Flux chains, buckets CLI, TSM tuning - do not transfer. This page covers 3.x.

The data model

Data arrives in line protocol:

sensors,host=web1,region=cn temperature=24.1,fan=1200i 1727000000000000000

• Measurement: the table-like namespace (sensors).
• Tags: indexed string dimensions (host=web1) - the filter axes at query time.
• Fields: the actual values (temperature=24.1); not indexed.
• Timestamp: nanosecond precision, from the client or assigned on write.

The classic way to take an InfluxDB down is tag cardinality explosion: putting a unique value - request id, user id, trace id - into a tag produces an unbounded number of index series and the engine chokes on index pressure. Tags must stay low-cardinality; unique values belong in fields.

Querying

Version 3 queries in SQL (DataFusion dialect) or InfluxQL. The work it is built for is time-bounded aggregation - downsampled means, percentile windows, last value per series - evaluated over Parquet files with predicate pushdown. Flux exists only in the 2.x line; new work belongs in SQL.

Writes and consistency

Writes arrive as line protocol over HTTP, batched per request. There are no multi-point transactions and no cross-measurement integrity - “the counter and the event both landed” is not a guarantee the engine provides. Durability comes from the write-ahead log plus object-store persistence in the 3.x architecture.

Tiers and scaling

• InfluxDB 3 Core: the open-source single-node engine (Apache 2.0 / MIT). One node, local disk or object storage.
• Enterprise and clustered tiers: commercial distribution adds clustering, replication, and longer retention tooling. Core has no built-in replication - high availability means the commercial tiers or your own backup-and-restore plan.

Operations

Core persists to object storage (S3-compatible) or local disk. The load is write-dominated; the watch items are ingest lag, compaction backlog, and WAL growth on disk-backed deployments. There is no vacuum and no planner statistics to babysit.

What actually breaks

• Tag cardinality explosion - a unique id in a tag produces an unbounded series count and the engine dies under index pressure. Unique values belong in fields.
• 2.x docs applied to 3.x - Flux snippets and TSM tuning guides do not transfer. Check the doc version header before following a recipe.
• Treating it as a system of record: no multi-object transactions means “the counter and the event both landed” is not guaranteed.

Where InfluxDB is the wrong choice

Relational time-series at moderate scale belongs in TimescaleDB, where ACID, joins, and the PostgreSQL toolchain still work. Business records needing transactions belong in a relational database. And if the real job is metrics monitoring, a scrape-based stack (Prometheus plus remote storage) is usually closer to the shape of the problem.