From AWS IoT SiteWise to Timestream for InfluxDB

At 56k.Cloud we run industrial IoT deployments where the data model gets big fast. For instance, one such project — station, platform and door-level monitoring across a transit network — needs to track around 260,000 individual data streams. We built the first version of that stack on AWS IoT SiteWise. A year later, we rebuilt it on Amazon Timestream for InfluxDB. Here's why, backed by numbers from our own PoC.

Where SiteWise held us back

SiteWise's core abstraction is the asset model: you describe your physical world as a hierarchy of assets, properties and relationships, and SiteWise manages the time-series storage underneath. That's a good fit when your infrastructure genuinely maps to a clean asset tree. Ours didn't. Stations, platforms and doors nested several layers deep with a lot of repetition, and the model felt rigid for what was, underneath, just time-series data.

That rigidity showed up most whenever the hierarchy itself needed to change. Adding, renaming or restructuring assets and properties was never a quick edit: each change took real effort to work through. And once our asset count grew into the hundreds of thousands of data streams, a single infrastructure deployment could take about an hour, so every hierarchy change also meant a long wait to see it applied.

Simpler IoT Rules

Getting data from AWS IoT Core into SiteWise was its own source of friction. The iotSiteWise rule action needs the payload shaped into a specific structure — asset/property IDs, typed values, a split timestamp — filled in entirely through the rule's SQL and substitution templates. At our scale that meant 21 separate SiteWise IoT Rules, one per property group, that had to be deployed, monitored and kept in sync with the station configuration. Moving to Timestream for InfluxDB collapsed that down to 2 ingest rules (one per MQTT topic family). The rule routes it to a single Lambda that writes the points to InfluxDB with the official client library. Far less to deploy and maintain.

The numbers

Before committing, we ran a PoC that sent the same API requests to both backends and compared p50 and p95 latency, using matched payload sizes and warmed-up runs.

Alarm queries are 5–19× faster on InfluxDB. SiteWise returns one property per call, so listing a door's active alarms meant one call for each alarm type the door can raise. InfluxDB returns all of them in a single query. End to end, door alarms dropped from about 2.6 s to about 0.3 s (8.6× faster). On the backend alone, they dropped from 2,369 ms to 127 ms (18.6× faster). The SiteWise time also grows with every alarm type you add, while InfluxDB's stays flat.

Reading a single value is slightly slower on InfluxDB. Each query takes a flat ~127 ms, against ~40 ms for a single SiteWise read, so about 75 ms more end to end. That is hard to notice next to the ~180 ms of API Gateway and authentication overhead that both stacks share.

One feature was originally designed around the SiteWise API, which works best with many small, independent requests. Carried over unchanged, that pattern ran noticeably slower on InfluxDB, which does better when a single query fetches everything at once. Once we changed how the feature reads its data, it ran 5.7× faster than the original design. Moving to a new storage engine also means revisiting access patterns that were built around the old one.

Trade-offs

As with any architecture or tool choice, it's important to match the tool to the shape of your data and pipeline. SiteWise still does things Timestream for InfluxDB doesn't: native asset-hierarchy modeling, built-in storage tiering, and ingestion without any application code when your payloads are simple JSON. For a large repetitive asset structure with alarm-heavy queries and a hierarchy that changes over time, the move paid off in query performance, ingestion simplicity, and iteration speed.