How Axpo's IoT Platform Ingests 150 Million Rows a Day from 20+ Power Plants with Tiger Data

Switzerland's largest power producer runs an IoT platform on Tiger Cloud, ingesting sensor telemetry from more than 20 power plants after outgrowing Microsoft SQL Server and then a storage-bound managed TimescaleDB service on Azure.

Axpo is Switzerland's largest power producer and a global leader in energy trading and renewable marketing. Its IoT platform ingests 150 million time-series rows a day from more than 20 power plant systems. The team moved off Microsoft SQL Server to TimescaleDB after SQL Server had performance issues, then migrated from the Managed Service for TimescaleDB on Azure to Tiger Cloud on AWS when storage ran out of room to grow. Lead Software Engineer Emanuel Joos led that migration. A single Postgres hypertable now backs everything from operator troubleshooting to customer-facing dashboards.

About Axpo Running a fleet of power plants means capturing telemetry from every plant's control system, continuously, and never stopping. A single hydropower or grid connection produces readings from thousands of sensors, many of them sampling every second. When an operator needs to understand what happened on a turbine last Tuesday, or a customer wants to see a year of output for a specific signal, the data has to be there and it has to come back fast.

A general-purpose relational database is not built for that shape of work. The write volume alone overwhelms it, and time-range queries over years of history turn into multi-minute waits. That is the wall Axpo hit, and it is the wall their application was built to remove.

Axpo built an IoT application for exactly this use case. Internal users and external customers connect to power plants, both Axpo's own and customer-owned, and the platform ingests IoT and SCADA telemetry straight from those plants' control systems. A visualization frontend lets a user pick arbitrary signals from a catalog of roughly 200,000 sensors, plot them across very long time ranges, and pan and zoom through the history. Every zoom triggers a fresh downsampling query, so detail sharpens as the user narrows the window. Operators use the same tool to inspect any single signal's history in under a second, work that took minutes on the legacy system it replaced.

Axpo employs around 6,000 people and is headquartered near Zurich, with subsidiaries trading globally.

The challenge: outgrowing SQL Server, then a storage ceiling on Azure Axpo's first version of this system ran on Microsoft SQL Server, a general-purpose relational database that was never built for high-rate sensor data. Three limits showed up fast:

• Ingest throughput. SQL Server could not keep up with the continuous, high-frequency inserts streaming off the plants' sensors.

• A hard storage ceiling. With only two power plants connected, the database filled to capacity within months and stopped accepting new writes.

• Slow queries. The time-range lookups operators depended on were already taking minutes, slow enough to get in the way of diagnosing a plant. Once the database filled, it could no longer insert or query, and the whole system crashed.

With longtime engineer Bastian leading the move, Axpo migrated off SQL Server to TimescaleDB, the open-source PostgreSQL extension for time-series data, run as the Managed Service for TimescaleDB (MST) on Azure. The ingest and capacity problems went away. The team connected more than 20 systems and kept inserting around 150 million rows a day. But as the data grew, MST exposed a different limit: storage.

MST coupled storage to compute. The only way to add disk was to move up to a larger CPU and memory tier the team did not need. And Axpo never deletes historical data, while continuously connecting more power plants, so the storage requirement only ever goes up. Pre-provisioned storage tied to a compute tier is the wrong cost model for a workload that grows in one direction forever.

Why Tiger Cloud

By 2025 the journey had two clear lessons. Microsoft SQL Server could not handle the ingest. MST (Managed Service for TimescaleDB) on Azure handled the ingest but tied storage to compute. Axpo wanted to keep TimescaleDB and fix the storage model, not re-architect, so the same hypertable, the same SQL, and the same downsampling functions would carry over unchanged. They migrated their managed deployment from Azure to Tiger Cloud on AWS in 2025, driven by four things:

• Tiered storage and independent scaling. This was the primary driver. Tiger Cloud lets storage grow on its own, so Axpo can keep adding plants and history without buying compute they do not use.

• Long-term retention that stays queryable. Axpo keeps roughly three years of data hot and tiers the rest, more than ten years, to low-cost Amazon S3 storage that is still queryable through SQL.

• Production operations. Automatic upgrades, better observability and logging, and a production support agreement with 24/7 severity-based paging.

• Usage-based storage. Pay for the storage in use instead of pre-provisioning a fixed allocation.

Because the move kept TimescaleDB at the center, Axpo did not split analytics into a second system or rewrite their application. The data model stayed the same. The platform underneath it changed.

Inside Axpo's Tiger Data stack

A serverless ingestion function pulls live data from each power plant's control system, transforms it, and streams inserts into TimescaleDB on Tiger Cloud, running on AWS. Everything lands in a single hypertable: measurements with a timestamp, a signal ID, and a measurement value. That one table holds roughly 200,000 distinct sensor signals and grows by about 150 million rows a day.

Compression runs on daily chunks, ordered by time descending and segmented by signal ID, which keeps recent history dense and cheap to scan. The team manages late-arriving data with cutoff windows so inserts do not land in already-compressed chunks. Older data tiers automatically to Amazon S3 and stays queryable, which is how Axpo holds a decade-plus of history without growing the hot tier.

The database does more than store rows. It runs heartbeat checks to confirm each plant link is alive, resamples signals, and aligns time-series for downstream machine learning. The visualization frontend leans on the LTTB (Largest Triangle Three Buckets) downsampling function: every pan and zoom issues a fresh LTTB query, typically returning around 2,000 points, so the chart shows the true shape of a signal without loading millions of raw readings. Around TimescaleDB, the team runs Databricks for ML and Spark batch workloads, Grafana for customer-built dashboards, and Alembic for schema migrations.

Results

150 million rows a day, and queries that still come back

On the same hypertable, Axpo ingests about 150 million rows a day from more than 20 connected systems, and the system holds up. The contrast with the MSSQL version, which crashed at two plants, is the whole point of the migration.

Sub-second signal lookups for operators

Operators inspect any single signal's full history in under a second. On the MSSQL system that work took minutes, slow enough to get in the way of diagnosing a plant. The speed comes from TimescaleDB's time-based partitioning, which keeps queries bounded as the table grows, and from compression on older chunks.

Smooth visualization over years of data

A signal sampled every second produces more than ten million points across a year. A screen has about two thousand pixels. Loading the raw series to draw a chart makes no sense, so the application uses LTTB to resample on every pan and zoom, returning roughly two thousand points that preserve the shape of the signal. The result is a responsive chart over arbitrarily long time ranges.

Retention without re-architecture

Because Axpo never deletes data and keeps adding plants, retention is a permanent cost question, not a one-time one. Tiered storage answers it: three years stay hot, the rest tiers to Amazon S3, and all of it stays queryable in SQL. Storage grows on its own line item instead of forcing a jump to a bigger compute tier. The team also extended access outward, so customers now build their own Grafana dashboards on the same Tiger Cloud data.

Looking ahead

Axpo is still connecting systems. Hydropower and grid connections are in place, a hydrogen plant is connected, and more plants are planned. Each one adds signals to the same catalog and rows to the same table.

The decision that compounds as Axpo scales is not any single number. It is that everything runs on one TimescaleDB hypertable: ingestion from every plant, the heartbeat and resampling logic, the machine-learning feature prep, the operator lookups, and the customer dashboards. There is no split architecture to keep in sync and no second query path to reconcile as the fleet grows. Adding a plant does not change the data model. It just makes the table bigger, and tiered storage means a decade of history scales on storage cost rather than on a compute tier the team does not need.