Design Trade-offs of a Multi-Tenant IoT Platform: How Much Isolation Is Enough
Turning a single-tenant IoT platform into a SaaS looks like "just add a tenant_id field" — until you actually start, and every layer asks the same question: how much isolation is enough?
Three Tiers of Data Isolation
| Approach | Isolation | Cost | Best for |
|---|---|---|---|
| Shared tables + tenant_id | Weak | Lowest | SMB customers, standardized features |
| Separate schema | Medium | Medium | Customers with customization needs |
| Separate database | Strong | Highest | Large customers, compliance-sensitive industries |
What makes IoT scenarios special is that the data comes in two layers: business data (device profiles, alerts, users) is small in volume but complex in structure, while time-series data (telemetry) is huge in volume but simple in structure. There's no need for a one-size-fits-all approach — a common pragmatic choice is shared tables for the business database plus tenant-tagged time-series data, with tenant filtering uniformly injected at the query layer.
The Hidden Costs of Shared Tables
If you choose the cheapest option — shared tables — the bill arrives in these places:
- The authorization defense lives in code: every SQL statement, every cache key, and every message subscription must carry the tenant context; a single miss anywhere is a horizontal privilege-escalation vulnerability. Inject it uniformly with an ORM interceptor/plugin rather than relying on developer discipline;
- Noisy neighbors: when one tenant's tens of thousands of devices report in a burst, shared resources (connection pools, thread pools, write bandwidth) get squeezed and every other tenant jitters along. You need per-tenant rate-limit quotas;
- Backup and deletion: exporting a single tenant's data or deleting it on account closure means "carving" rows out of shared tables — no small amount of work under GDPR-style compliance requirements.
Tenant Awareness at the Connection Layer
The MQTT access layer is no exception: device authentication must resolve which tenant a device belongs to, and Topic permissions must be isolated per tenant — a device of tenant A must never be able to subscribe to a Topic of tenant B. It's best to configure the broker's ACL rules once with wildcards plus a tenant prefix, rather than writing a rule for every device.
My Recommendations
- Early stage: shared tables + strict tenant-context injection, with "isolation correctness" covered by automated test cases;
- When a large customer arrives: deploy a dedicated instance for them (separate database + separate broker cluster) — isolation through configuration;
- Tag time-series data by tenant from day one; it has the lowest migration cost.
The essence of multi-tenant design is not technology selection, but finding the balance between commercial pricing and technical complexity: the stronger the isolation, the higher the per-customer cost. Make isolation an optional tier and let it become part of your pricing system.