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

How can you work with millions of IoT measurements efficiently? Learn how PostgreSQL and TimescaleDB transform time-series data into valuable insights.

Andri Örvar Baldvinsson

Insights

IoT sensors are more than thermometers.
They're in machines, vehicles, factories, and power plants, constantly pumping out data every second (or faster). All day. Every day.

They measure things like:
⚙️ machinery sending continuous information about temperature, load, and wear
🚚 vehicles reporting speed, fuel consumption, location, and vehicle health
electrical systems tracking load and anomalies
🌡️ weather and environmental sensors recording temperature, wind, precipitation, and air quality
🏭 production lines monitoring performance and deviations
🏙️ municipal infrastructure like traffic, lighting, and waste collection

These are all time-series data: large volumes, continuous flow, and very little tolerance for delays.

And that's when problems start:
data piles up, queries slow down, and working with the data becomes difficult.

How do you handle this volume of data?
And how do you turn raw sensor readings into actionable information, real insights, and better decisions?

Many have chosen to set up specialized time-series databases (like InfluxDB) designed specifically for this kind of data. They come with tradeoffs — usually, users need to learn a new query language. And these databases don't work well for "regular" data connected to the time-series.

To tackle this kind of challenge, we've turned to PostgreSQL with TimescaleDB. Both PostgreSQL and TimescaleDB are open source (TimescaleDB has a community edition), and together they create a database that:

  • Handles hundreds of millions (or billions) of records

  • Keeps data looking like standard SQL tables

  • Splits data into smaller chunks based on time periods

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

  • Automatically refreshes summaries (aggregates) from your data

  • Uses standard SQL for queries

Since you can use standard SQL for queries and work with time-series data just like any other data in PostgreSQL, IoT data doesn't need to live in a separate system. It works right alongside other datasets.

You can also connect time-series data to:

  • geographic data (GIS) — like the location of machines, sensors, or infrastructure

  • text and search data — like incident descriptions and maintenance logs

  • AI and analytics tools — helping you find patterns, anomalies, and connections you might otherwise miss

This opens up a completely different approach to analysis and operations — where data is no longer just numbers in a table, but part of a larger context you can query, connect, and process.

"Being able to work with IoT data in a regular PostgreSQL environment simplifies everything. Operations become more efficient because our team can use the PostgreSQL knowledge that's already here, and we don't need to learn how to run a new database or keep it running. Users skip having to learn a new query language and manually connecting data between systems."

Snorri Bergmann - Database Specialist, APRÓ

When machines start talking, and you can talk back

With MCP services and AI connected to PostgreSQL databases, we've moved beyond reports and into conversations with data:

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

  • What changed just before this failed?

  • Where are the first signs of wear?

  • Which machines are likely to fail next?

  • How did Iceland's temperature in 2023 compare to previous years?

Cloud or on-premises? Same solution.

It runs on AWS and Azure when that makes sense, but often on-premises instead, because you usually want data to stay close to your machines and sensors for both speed and cost — constant data transfer to the cloud can get expensive fast.

The bottom line:

By using PostgreSQL with TimescaleDB, we get the ability to work with time-series data right within the PostgreSQL ecosystem. That means lower licensing costs, less operational risk, more flexibility, and you get to keep using the knowledge your team already has instead of learning new tools and changing how you work.


Contact us