SQL to NoSQL redesign for real-time IoT data

Relational databases excel when you need strong relationships, multi-row transactions, and ad-hoc joins across a normalised schema. High-frequency IoT telemetry is a different problem: mostly append-only writes, queries scoped by device or facility and time range, and retention policies that treat last week’s readings differently from last year’s. Forcing that workload through row-oriented tables and secondary indexes creates write amplification and operational cost without buying you the join flexibility you actually use.

The redesign started with access patterns, not with a favourite NoSQL product. We mapped what the product needed in the first seconds after a reading arrives, what facility dashboards query repeatedly, and what analytical or AI workloads could tolerate a short delay. That split drove which data stayed relational (configuration, users, facility metadata) and which moved to a purpose-built NoSQL path for telemetry.

On AWS, we moved sensor streams onto a NoSQL design suited to time-series keys and high write throughput — with partitioning that spreads load by facility and device rather than funneling everything through a single hot table. Ingest was decoupled from query: devices and edge gateways publish events into a streaming path, consumers write durable telemetry records, and read models serve the live views the product needs without scanning a transactional store.

Migration was incremental. New readings landed in the NoSQL store while historical windows were backfilled in controlled batches. Application read paths switched by feature and facility cohort, with dual-running long enough to prove parity on the dashboards operators rely on. The SQL database did not disappear — it kept owning the relational domain — but it stopped being asked to be a telemetry warehouse.

Once telemetry sat in a model matched to how it is written and read, ingest kept up under peak load, live facility views stopped competing with bulk writes, and the bill for database capacity dropped — because the platform was no longer scaling a relational engine to compensate for the wrong workload shape. Operationally, retention and archival became explicit policies instead of emergency disk cleanup.

Just as important, the new path unblocked the product roadmap. AI agents that interpret sensor patterns and collaborate with facility managers need fresh, queryable data and predictable latency. Those features sit on top of the NoSQL foundation rather than fighting the old SQL bottleneck — which is why this migration was not only a cost play, but the prerequisite for the monitoring intelligence the manufacturer wanted to ship next.

Start from access patterns and retention, keep relational data relational, and migrate telemetry behind clear service boundaries so the application can cut over gradually. Measure ingest lag, query latency, and unit cost before and after — those are the numbers that convince both engineering and finance that the redesign worked.

For IoT platforms growing into AI, the database decision is a product decision. Get the data path right, and everything built on top moves faster. Get it wrong, and no amount of model quality will make a slow, expensive foundation feel intelligent.