A time series database (TSDB) for IoT is a database built to ingest timestamped readings from sensors, meters and machines at high speed, store them compactly and query them by time range. On an Internet of Things (IoT) site, it handles the three jobs that strain an ordinary relational database: constant writes, automatic retention and time-based aggregation.
Key takeaways
- A time series database partitions data by time, compresses it column by column and drops or summarises old data in a single operation.
- A relational table copes with a few dozen sensors read once a minute; thousands of series and sub-second readings need a purpose-built approach.
- Four common routes exist: a plain relational table, a relational database with a time series extension, a purpose-built time series database or an industrial historian.
- Per Siemens' 2024 report, a large plant loses around 27 hours a month to unplanned downtime; failure analysis needs retained sensor history.
- Derive the retention policy from real questions: keep raw data briefly, per-minute summaries longer and hourly summaries for years.
Why sensor data outgrows an ordinary table
It usually starts innocently. A plant fits temperature, vibration and current sensors to 40 machines, each reporting once a second, and the readings go into a "measurements" table in the same relational database that runs an application or the ERP (enterprise resource planning) system. A few months later that table holds hundreds of millions of rows, last month's hourly average takes minutes to return and the disk is filling faster than anyone planned.
The slowdown is not the relational database's fault; the workload is simply different. An order or invoice is written once, updated occasionally and read individually. Sensor data is the opposite: it is appended continuously, almost never updated and nearly always read as a time range, usually summarised.
As sensor data volumes grow, teams end up with two poor options. Either raw data is purged regularly and nobody can look back after a failure, or it is kept but queries are too slow to be useful. A time series database removes the dilemma by partitioning data along the time axis, compressing it and summarising it as it ages. Sensor data is a typical example of the volume and velocity sides of big data; we explain the concept in what is big data.
What does losing sensor history really cost?
The volume of data measured in the field keeps climbing. According to IoT Analytics' State of IoT 2025 report, the number of connected IoT devices was expected to grow 14% to 21.1 billion in 2025 and reach 39 billion by 2030. Every one of those devices is a time series that someone has to store and query.
The real value of that history shows up when something goes wrong:
Siemens, in a report produced with its predictive maintenance business Senseye, estimates that the world's 500 largest companies lose almost $1.4 trillion a year to unplanned downtime, equivalent to 11% of their revenues. (Siemens/Senseye, The True Cost of Downtime 2024)
The same Siemens report finds that a large manufacturing plant still loses around 27 hours a month to unplanned downtime. Root-cause analysis with manufacturing data and predictive maintenance models both depend on the days of sensor data leading up to a failure. If that history was deleted to free disk space, or is too slow to query, the analysis is over before it begins.
Trust in the data matters too. In the 2025 Outlook: Data Integrity Trends and Insights survey (2024) by Drexel University's LeBow College of Business and Precisely, a vendor of data integrity software, 67% of respondents said they don't fully trust the data their organisation uses. With sensor data, the usual culprits are gaps, duplicates and clock drift, and a well-designed time series store makes all three visible rather than hiding them.
How a time series database for IoT works
A time series database stores each measurement as a four-part record: a timestamp, a measurement name (temperature, say), the measured value and a set of tags (site, line, machine, sensor ID). Tags are the dimensions you filter on; values are the numbers you analyse. Get the tag-versus-value split wrong, for instance by turning a unique reading ID into a tag, and cardinality (the number of unique tag combinations) explodes and performance falls away.
Under the hood, a time series engine splits data into time chunks, such as a day or a week, and compresses each chunk column by column. Because consecutive sensor readings tend to be very similar, compression is far more effective than in row-based relational storage. Old chunks can be dropped or moved to cheaper storage with a single operation instead of deleting rows one at a time.
The third capability of a time series database is time-aware querying. Functions such as "average per five-minute bucket", "fill gaps with the last known value", "latest reading" and "difference between two series" are built in. Continuous aggregates compute hourly and daily summaries as data arrives, so a dashboard does not rescan millions of rows every time someone opens it.
What are the time series database options for sensor data?
"Time series database" is not a single product category. Depending on scale, in-house skills and where the data needs to go next, there are four common routes:
| Option | Best suited to | Strength | Watch out for |
|---|---|---|---|
| Plain relational table | A few dozen sensors, per-minute readings, short history | No new infrastructure, familiar to the team | Query speed and disk usage as volume grows |
| Relational database with a time series extension | Joining sensor data with business data in one SQL environment | Standard SQL, joins, familiar backup tooling | Schema and partitioning need designing up front |
| Purpose-built time series database | Thousands of series, sub-second readings, heavy write loads | High ingest rates, built-in retention and downsampling | Different query language; joining with business data needs extra integration |
| Industrial historian | SCADA/PLC-centric plants, operator-facing trends | Ready-made connectors for field protocols | Opening data to other systems and the licensing model can be limiting |
Choosing a time series store sits alongside, not instead of, the data lake versus data warehouse question. High-frequency raw data stays in the time series store, while hourly and per-shift summaries flow into the data warehouse to be combined with production, quality and cost data.
How do you set up a time series database? Seven steps
- Write down the questions first. "Vibration trend in the 72 hours before a failure", "energy use per shift" or "threshold breaches in the cold room" determine how much history you need and at what resolution.
- Build a sensor and signal inventory. List each signal's unit, sampling rate, source (PLC, meter, wireless sensor) and owner. On older equipment, working out where a signal can be picked up is part of retrofitting legacy machines; OPC UA is a common way to read PLC (programmable logic controller) and SCADA data through a standard model.
- Design the data model. Agree the tag-versus-value split, a naming convention and a cardinality limit in writing; this is the most expensive decision to change later.
- Set up the ingestion layer. Field devices usually publish to a messaging layer such as MQTT. MQTT's QoS 1 (Quality of Service, "at least once" delivery) level reduces the risk of loss but can produce duplicates, so the write path must tolerate them. The LoRa vs NB-IoT vs cellular comparison helps with the connectivity choice.
- Agree a retention and downsampling policy. A typical pattern keeps raw data briefly, per-minute summaries longer and hourly summaries for years. Derive the policy from the questions in step one; "keep everything forever" is not a policy.
- Add quality rules. Late and out-of-order data, device clock drift, physically impossible values and gaps should be caught and flagged. Our guide to data quality and duplicates covers the general principles.
- Connect the consumers. Remote monitoring screens, alert rules, BI reports and AI models all read from the same store, with access rights and separation from the plant network defined according to OT (operational technology) security principles.
Regulation can shape sensor data retention too (as of October 2026). In Türkiye, the Energy Efficiency Law No. 5627 requires industrial plants, and building managers obliged to employ an energy manager, to submit requested consumption data to the General Directorate by the end of March each year. The law does not set a specific retention period, but keeping meter summaries for at least one full reporting period makes that submission far easier to back up; confirm your own scope with your legal adviser or energy manager.
Common mistakes in time series database projects
The first mistake in time series projects is sizing for today's sensor count. A pilot starts with 20 sensors and a year later spans three sites and thousands of signals, so partitioning and retention choices should allow for that growth. The second is trusting device clocks blindly; document whether the timestamp is assigned on the device, at the gateway or on the server. If data is pre-processed on site, the same rule applies to the edge computing layer.
The third is treating the time series store as a reporting database. Management rarely needs per-second raw data; it needs well-defined indicators, which our guide to BI dashboards and KPIs explores in detail. Finally, decide how fresh each view needs to be based on genuine real-time reporting needs; not every screen has to update every second.
How does Digital Bridge build a sensor data platform?
At Digital Bridge, we start sensor data projects with a needs assessment: which decisions will rely on sensor data, which signals exist, how much history is needed and who will own the data. During discovery we review the existing PLC, SCADA and metering set-up on site, and where off-the-shelf hardware falls short we look at custom IoT device design and manufacturing.
Next comes a pilot on a single line, station or energy point. The data model, retention policy and quality rules are tested against real readings, and query times and disk growth are measured. For remote sites, data flows into our remote monitoring platform, where alerts, maps and trend screens all draw on the same store.
The final phase of the project is integration. We move hourly and per-shift summaries alongside ERP and production data through data warehouse and ETL (extract, transform, load) pipelines and present them to management via a BI dashboard. The same history then feeds predictive maintenance models and energy monitoring and management reports. If you are weighing up the budget for a sensor data platform, our article on data warehouse cost factors breaks down what drives it.
Your next step
Let's look together at where your sensor data lives today, how far back you can go and which questions you currently cannot answer. Get in touch with a signal inventory, or simply a list of machines, and we will send back a proposed pilot scope and the storage option that fits. For more guides, visit the Data & Analytics topic page.