Multi-tenancy shows up whenever a platform serves more than one distinct customer organization from shared infrastructure — a B2B IoT platform sold to multiple companies, each with their own devices, users, and data that must never be visible across tenant boundaries. Getting the isolation model right early avoids both a security incident later and an expensive architectural migration if the wrong model was chosen at the start.
Three common isolation models
| Model | Isolation strength | Operational cost |
|---|---|---|
| Silo (separate database/instance per tenant) | Strongest | Highest — N databases to manage, patch, scale |
| Pool (shared database, tenant ID on every row) | Weakest without careful enforcement | Lowest — one database to operate |
| Bridge (shared infrastructure, isolated schemas/namespaces per tenant) | Moderate-strong | Moderate |
Silo: strongest isolation, highest operational cost
A fully siloed model gives each tenant a dedicated database (or even a fully dedicated infrastructure stack), making cross-tenant data leakage close to structurally impossible — there's no shared table a bug could accidentally query across. The cost is operational: managing, migrating, scaling, and monitoring N separate databases instead of one grows linearly with tenant count, and becomes a real burden past some tenant scale unless heavily automated. This model tends to fit platforms with a small number of large enterprise tenants, particularly where regulatory or contractual requirements mandate strict data separation.
Pool: shared infrastructure, isolation enforced in application logic
A pooled model puts all tenants' data in shared tables, distinguished by a tenant identifier column, with every query filtered by that identifier. This is operationally the simplest to run — one database, one schema, one set of infrastructure to scale — but isolation is only as strong as the discipline enforcing that every single query correctly filters by tenant. A missed filter in one code path is a real, not theoretical, cross-tenant data leak risk, which is why platforms using this model typically add enforcement at more than one layer — database row-level security policies in addition to application-level filtering, so a single missed application-layer check doesn't result in an actual leak.
Bridge: a middle ground that fits many IoT platforms well
A bridge model shares underlying infrastructure but gives each tenant a separate schema or logical namespace within it — stronger isolation than a fully pooled model without the full operational cost of a fully siloed one. This tends to be a practical fit for IoT platforms serving a moderate number of mid-market tenants, where full per-tenant infrastructure isn't justified but "isolation enforced entirely by application code" feels too risky given the data (device telemetry, potentially location or usage data) involved.
Device provisioning has to respect tenant boundaries too
Isolation isn't only a database concern — device provisioning, authentication, and the MQTT topic structure (if using a pub/sub protocol) all need tenant boundaries baked in. A device's credentials and topic namespace should make it structurally difficult, not just procedurally discouraged, for a device or client authenticated as one tenant to publish to or subscribe to another tenant's topics.
Regional data residency compounds the isolation question
For platforms serving tenants across multiple regulatory regions, data residency requirements (data physically stored within a specific region) add another dimension on top of tenant isolation — a tenant's data may need to stay within a specific geography regardless of which isolation model is chosen, which affects infrastructure placement, not just data modeling.
How we approach this
We choose the isolation model based on tenant count, data sensitivity, and regulatory requirements specific to the product, rather than defaulting to whichever model is operationally simplest. See our cloud & device platform work for how this fits into a full platform build.