A time-series database is the layer on which every serious IoT project stands or falls. Sensors for temperature, vibration, or energy consumption generate a stream of measurement points that a classic relational database simply cannot handle at production scale. A well-chosen time-series database (TSDB) lets you write millions of measurements per second, compress them by an order of magnitude, and query them by time range in milliseconds. In this guide we explain how a TSDB works, which one to choose, and how to design retention, downsampling, and a data model for a device fleet.
In short: a time-series database is a storage system optimized for timestamped data — in IoT it is responsible for ingesting telemetry from thousands of devices, compressing it, retaining it, and serving fast analytical queries. The most commonly chosen options are InfluxDB, TimescaleDB, Azure Data Explorer, and ClickHouse.
What is a time-series database?
A time-series database is a specialized engine for storing sequences of measurements ordered in time, where every record has a timestamp, a set of tags (e.g., device ID, location), and one or more values. Unlike a relational database, the data is almost exclusively appended (an append-only model) rather than modified.
That single characteristic changes everything. A TSDB engine can assume that new records arrive chronologically, which lets it apply differential compression (delta-of-delta for timestamps, XOR compression for floating-point values), time-based indexes, and partitioning into time blocks. The result is typically a 5–15× reduction in volume and write rates of hundreds of thousands of points per second on a single node.
Why does IoT need a time-series database?
IoT is, by definition, a time-series problem: measurement, timestamp, repeat. A fleet of 10,000 devices reporting 10 metrics every 10 seconds generates about 100,000 points per second and more than 8.6 billion records per day. A relational model with a B-tree index degrades at that write rate, and IOPS costs rise steeply.
Telemetry usually reaches the database through a message broker. In practice we combine the MQTT protocol at the edge with a cloud event queue such as Azure Event Hubs, and only from there is the stream written to the TSDB. Such a pipeline separates ingestion from storage and lets you buffer traffic peaks. We describe the streaming layer in more detail in our piece on real-time IoT telemetry.
How does a time-series database work?
A time-series database operates in three logical stages: accepting the write (ingest), durable storage with compression, and reading by time range. Understanding these stages is key to designing an efficient deployment.
- Ingest — writes first land in an in-memory structure (WAL + buffer), are sorted by time, and are periodically flushed to disk as immutable blocks.
- Compression and partitioning — blocks are divided into time windows (e.g., 1–7 days); older partitions can be compressed more aggressively or moved to cheaper storage (tiering).
- Queries — the engine reads only the partitions covering the query's time range and performs aggregations (avg, min, max, percentiles) with downsampling on the fly.
Which time-series database should you choose?
There is no single best time-series database — the choice depends on volume, query model, and the team's skills. Below are the most commonly deployed options and their strengths.
- InfluxDB — a dedicated TSDB engine with the Flux/InfluxQL language; a good starting point for deployments up to a few hundred thousand writes per second.
- TimescaleDB — a PostgreSQL extension, so full SQL, JOINs, and the Postgres ecosystem; convenient when the team already knows the relational model.
- Azure Data Explorer / ClickHouse — columnar analytical engines that scale to petabytes; they excel at heavy analytics and long history.
- Prometheus — the standard for infrastructure monitoring and operational metrics, but not for long-term storage of business data.
In projects on the Azure platform, we most often combine a TSDB with ready-made analytics services — we described this in our write-up on time-series analytics. It is worth backing the choice with a real load test on your own data profile rather than the vendor's benchmark alone.
Retention, downsampling, and compression — how not to sink the budget
Retention is the policy that determines how long the database keeps data at full resolution before it is aggregated or deleted. Without it, volume grows linearly and after a year can exceed the infrastructure budget tenfold.
A proven pattern is the resolution pyramid: keep raw data (e.g., every 1 s) for 7–30 days, 1-minute aggregates for 1 year, and hourly aggregates for several years. Downsampling — automatically computing and storing aggregates — is handled by background jobs (continuous queries, materialized views). This way a historical dashboard reads lightweight aggregates instead of billions of raw points.
How to design the data model and analytics?
The performance of a time-series database depends mainly on cardinality — the number of unique tag combinations. Putting high-uniqueness values into tags (e.g., a random UUID in every measurement) can blow up the index and slow down queries. Tags should describe dimensions with a finite number of values: device ID, sensor type, production line.
On data prepared this way it is easy to build higher-order analytics. The stored series feed real-time dashboards and anomaly-detection and alerting mechanisms that are at the heart of predictive maintenance. We expand on this thread in our article on predictive maintenance in IIoT.
Frequently asked questions (FAQ)
How does a time-series database differ from an ordinary SQL database?
A time-series database is optimized for append-only, timestamped writes, columnar compression, and time-range queries. A classic relational database loses performance at millions of points per second and has no built-in retention or downsampling.
How much data does a typical IoT fleet generate?
A fleet of 10,000 devices sending 10 metrics every 10 seconds is about 100,000 points per second, or more than 8.6 billion records per day. Without compression (usually 5–15×) and a retention policy, storage cost grows linearly and quickly exceeds the project budget.
Which time-series database should you choose for an IoT project?
InfluxDB and TimescaleDB work well for most mid-scale deployments, Azure Data Explorer and ClickHouse for petabyte analytics, and Prometheus for infrastructure monitoring. The choice depends on write volume, query model, and whether the team prefers SQL or a dedicated language.
Summary and key takeaways
A time-series database is not an implementation detail but a foundation that determines the cost, performance, and scalability of the entire IoT system. The key decisions are the choice of engine (InfluxDB, TimescaleDB, Azure Data Explorer), the retention and downsampling policy, and control of tag cardinality. Designed correctly, they can handle billions of measurements per day at a predictable budget.
At FSS we design the full chain — from firmware and hardware, through telemetry ingestion, to the cloud and analytics. If you are planning to deploy telemetry for a device fleet, explore our offering for IoT analytics and dashboards and let's talk about a time-series architecture matched to your scale.