← Database Systems Hub
Database Systems · Guide

InfluxDB (Time Series)

Metrics, timestamps, retention, downsampling.

— min read Database Systems

Theory

InfluxDB (Time Series): Metrics, timestamps, retention, downsampling.

InfluxDB is a purpose-built time-series database (TSDB) optimized for high-ingest workloads — millions of data points per second. Unlike PostgreSQL with a TimescaleDB extension, InfluxDB's storage engine (TSM — Time-Structured Merge Tree) is designed from scratch for time-series: data is inherently ordered by time, old data is compressed aggressively, and range queries by time are the primary access pattern.

Data model: a measurement is analogous to a table. Each data point has a timestamp, one or more tags (indexed string key-value pairs — device_id, region), and one or more fields (unindexed numeric or string values — temperature, cpu_usage). Tags are used in WHERE clauses and GROUP BY; fields are what you measure. High-cardinality tags (user_id with millions of values) cause performance problems — put those in fields instead.

InfluxQL (1.x) is SQL-like: SELECT mean("cpu") FROM "system" WHERE time > now() - 1h GROUP BY time(5m), "host". Flux (2.x) is a functional data scripting language: from(bucket:"metrics") |> range(start: -1h) |> filter(fn: (r) => r._measurement == "cpu") |> mean(). Flux is more powerful but has a steeper learning curve. InfluxDB 3.x uses Apache Arrow Flight SQL.

Retention policies: automatically delete data older than a specified duration. InfluxDB 1.x: CREATE RETENTION POLICY "30d" ON "mydb" DURATION 30d REPLICATION 1 DEFAULT. InfluxDB 2.x uses bucket retention in the UI or CLI. Use multiple retention policies/buckets for different data: raw 30-day metrics, downsampled 1-year aggregates.

Downsampling: aggregate high-resolution data into lower-resolution summaries for long-term storage. InfluxDB 1.x Continuous Queries auto-aggregate on schedule. InfluxDB 2.x uses Tasks (Flux scripts triggered on a schedule) to compute hourly averages from per-second data and write to a "downsampled" bucket. This reduces storage cost for historical data by 100–1000×.

Telegraf is InfluxDB's data collection agent. It has 200+ input plugins (system CPU/memory, MySQL, Docker stats, SNMP, MQTT, HTTP JSON endpoints) and 50+ output plugins (InfluxDB, Prometheus, Kafka, CloudWatch). A Telegraf config file specifies [[inputs.cpu]], [[inputs.mem]], and [[outputs.influxdb_v2]] — collecting and forwarding metrics without writing custom collection code.

InfluxDB Cloud vs OSS: Cloud is fully managed, serverless, and billed per data in/out. OSS requires you to operate the cluster. InfluxDB Clustered (3.x) and the open-source IOx (InfluxDB I/O Experimental) engine use Apache Arrow + Parquet for columnar storage and object storage (S3/GCS) for durability — enabling unlimited retention and query at analytical scale.

Architecture Diagram

Users / clients
         |
  InfluxDB (Time Series)
         |
  Core services
         |
  Data + observability

Examples

bash 
# InfluxDB (Time Series)
# Metrics, timestamps, retention, downsampling.
# Validate in staging before production rollout.

Key Concepts

Data modelHow InfluxDB (Time Series) structures and queries data
ConsistencyGuarantees under failure and replication
Scaling axisVertical vs horizontal growth patterns
OpsBackup, monitoring, and upgrade path

Interview Questions

What problem does InfluxDB (Time Series) solve?

It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.

Key components of InfluxDB (Time Series)?

Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.

Common production pitfalls?

Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.

How do you test changes safely?

Staging parity, canary/gradual rollout, automated health checks, and documented rollback.

Metrics to prove success?

Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.

Beginner vs advanced concern?

Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.

Best Practices

  • Treat InfluxDB (Time Series) config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials.

Common Mistakes

  • Adopting InfluxDB (Time Series) without measurable success criteria.
  • No staging environment mirroring production constraints.
  • Missing rollback path during incidents.
  • Undocumented on-call expectations.

Cheat Sheet

InfluxDBMetrics, timestamps, retention, downsampling.
SLOService level objective
RollbackRevert to last known good
CanaryLimited blast-radius rollout
RunbookIncident steps

Practical Exercises

InfluxDB (Time Series) sandbox

Stand up InfluxDB (Time Series) locally or in free tier; document commands and failure recovery.

Failure drill

Introduce misconfiguration; practice detection and rollback under time limit.

← Graph Databases

Related topics