Do You Have IoT Data in Tons but Insights Measured in Grams?

IoT meters are not just thermometers.
They are in machines, cars, factories, and power plants, and they pump out data at second (or more frequent) intervals. Around the clock. Always.

They measure, for example:
⚙️ machines that constantly send information about temperature, load, and wear
🚚 vehicles that deliver data on speed, usage, location, and the car's condition
⚡ electrical grids and monitor load and anomalies
🌡️ weather and environmental meters that record, e.g., temperature, wind, precipitation, and air quality
🏭 production lines that monitor performance and anomalies
🏙️ municipal infrastructure like traffic, lights, and waste management

All of this is time-series data: high volume, constant flow, and with little patience for delays.

And that is when the problems start to creep in:
data piles up, queries become slow, and the data becomes difficult to work with.

How can this volume of data be managed?
And how do you turn raw measurements into usable information, real insights, and better decisions?

Many have chosen to set up specialized time-series databases (e.g., Influx) that are specifically designed for such data. They come with various disadvantages, e.g., users usually have to learn a new query language. Additionally, these databases are poorly suited for “normal” data associated with the time series.

To handle projects like this, we have been using PostgreSQL + TimescaleDB. PostgreSQL is open source and TimescaleDB is too (community edition), and together they form a database that:

• Accepts hundreds of millions of records (or billions)

• Data looks like standard SQL tables

• Splits data by time periods into smaller units

• Compresses data (up to ~98%) - sometimes from hundreds of GB to tens of GB

• Automatically updates aggregates from data 

• Standard SQL can be used in queries

Since standard SQL can be used in queries, you can work with the time-series data in the same way as other data in PostgreSQL. This means that IoT data does not need to be isolated in a dedicated system, but can work together with other datasets.

In addition, the time-series data can be linked to:

• geographic information system (GIS) data, e.g., the location of machines, meters, or infrastructure

• text and search data, e.g., incident descriptions and maintenance logs

• artificial intelligence and analysis tools, which make it possible to find patterns, anomalies, and contexts that might otherwise be missed

This opens up a completely different approach to analysis and operations — where the data is no longer just measurements in a table, but part of a larger context that can be queried, linked, and processed.

“Being able to work with IoT data in a standard PostgreSQL environment simplifies everything. Operations become more efficient because our team is able to utilize existing Postgres knowledge, and there is no need to learn how to operate a new database and get it up and running.  Users avoid having to learn a new query language and manually linking data between systems.”

Snorri Bergmann - database specialist at APRÓ

When machines start to talk and you can ask them questions in return

With MCP services and artificial intelligence connected to PostgreSQL databases, we have moved from reports to conversations with the data:

• Why did the machine shut down at 02:13?

• What changed right before this broke?

• Where do we see the first signs of wear?

• Which machines are most likely to fail next?

• What was the temperature in Iceland in 2023 compared to recent years?

Cloud or on-prem? Same solution.

Runs in AWS and Azure if that fits, but often on-prem, as you often want the data to be generated close to machines and meters, both due to latency and the cost of constant data transfer to the cloud.

Conclusion:

By using PostgreSQL with TimescaleDB, we gain the ability to work with time-series data  within the PostgreSQL ecosystem. That means lower licensing costs, less operational risk, greater flexibility, and that the knowledge already present in the team continues to be utilized, instead of having to change workflows and switch technology stacks.