Why Direct IoT Rule to Database Pipelines Fail
Wiring an IoT rule straight into a database is the fastest demo and the slowest outage. A look at backpressure, coupling, and the buffer you skipped.
The most common IoT architecture diagram in the wild is also the most fragile: device → broker → rule → database. It works beautifully in the demo and fails quietly in production, usually at the worst possible moment — when traffic spikes and the database is least able to absorb it.
This is a placeholder article. Here’s the shape of the argument.
The pattern that looks fine
An IoT rule matches incoming messages and writes them directly to a database. One hop, no moving parts, easy to reason about. For a prototype, it’s correct.
Why it fails at scale
- No backpressure. Devices don’t slow down because your database is busy. A write-amplifying spike has nowhere to go.
- Tight coupling. A schema change, a slow query, or a failover takes the ingestion path down with it.
- No replay. When a write fails, the event is gone. There’s no buffer to re-process from.
- Mixed concerns. Ingestion, transformation, and storage end up entangled in rule SQL that no one wants to touch.
The buffer you skipped
Putting a durable log or queue between ingestion and storage — a stream, a queue, a topic — decouples the rate at which devices produce from the rate at which storage can consume. It gives you replay, isolation, and a place to fan out to multiple consumers without touching the hot path.
A more durable shape
device → broker → rule → stream → consumers → storage / analytics / alerts
It’s one more box on the diagram and an order of magnitude more resilience.