Multi-tenant monitoring — what it means and who it serves

Multi-tenant monitoring sounds like a phrase from an investor deck, but behind it sits a question every cloud customer asks sooner or later: if my measurements live on the same platform as the data of hundreds of other companies, what exactly keeps them apart? The answer decides whether cloud monitoring can be used in a pharmacy, a hospital or a corporate group — everywhere "probably nobody will see it" is not an acceptable level of guarantee. Below we explain multi-tenant architecture in plain language: what it means, what the isolation looks like under the hood and who this design genuinely serves.

One building, many locked apartments

A tenant in this architecture is simply an organisation: a company, a subsidiary, a facility. A multi-tenant platform works like an apartment building — the utilities, foundations and roof are shared, but every apartment has its own lock, and a neighbour will not walk into your kitchen just because they "live next door". What is shared is the infrastructure: servers, updates, security monitoring on the provider's side. What is separate is each organisation's data, users, devices and configuration.

The alternative — a separate installation of the system at every customer — only sounds safer at first glance. In practice it means a server someone has to maintain and patch, updates rolled out "someday" and costs that rule smaller companies out from the start. The multi-tenant model reverses that equation: every fix and new feature reaches everyone at once, and starting a new organisation takes minutes, not weeks of deployment.

Multi-tenant monitoring under the hood: row-level security (RLS)

The key question is: what technically polices the boundaries between organisations? The simplest answer — "the application filters data by company identifier" — is also the weakest: one query written without the filter is all it takes for data to leak between tenants. That is why in Nextriv the isolation moved a floor down, into the database itself, in the form of Row-Level Security (RLS).

It works like this: every row of data — a reading, a sensor, an alert, a user — has an organisation assigned, and the RLS rules in the database enforce that a query executed in the context of one organisation simply does not see the rows of the others. It is not the application politely filtering out other people's data — it is the database refusing to return it. Even a programmer's mistake in the application layer does not open the door to a neighbour's data, because the lock is built into the foundation, not the door handle. In security engineering this is called defence in depth: the boundary between organisations does not depend on the flawlessness of every line of code above it.

Around the isolation: who gets in and what leaves a trace

Isolation itself is the foundation, but a multi-tenant architecture also needs order inside each "apartment". In Nextriv that order is built from four user roles with increasing permissions, organisation invitations valid for 7 days, two-factor login (TOTP with backup codes), a password policy and session management with global logout — useful when a phone with an active session changes hands.

On top of that comes accountability: an audit trail and a separate security event log, retained for 5 years, answer the question "who changed what and when" — without which no inspection gets done. And when the relationship ends, an organisation can delete its own account and data self-service, in line with GDPR requirements. A full overview of these mechanisms is on the platform security page, and a practical discussion of encryption and auditing — in our article on sensor data security.

Multi-tenant is not the same as multi-site

The two concepts are often confused, yet they answer different questions. One company with ten stores is one tenant with many locations: a shared dashboard, shared users, alerts and reports per facility — how to set that up is described in our article on multi-site monitoring. The tenant boundary runs where the organisational boundary runs: separate companies in a corporate group, independent franchisees or entities with different data controllers set up separate tenants — each with its own users, data and configuration, separated at the database level.

A simple heuristic: if two data sets have different legal owners, they should live in different tenants. If they share an owner and differ only by address — they are locations within one tenant.

Who this architecture serves

• Small companies — because it removes the entry barrier: zero infrastructure of your own, a start measured in minutes, and security patches deployed by the provider, not by the "IT person for everything".
• Regulated organisations — pharmacies, laboratories, healthcare — because the auditor's question "what separates your data from other customers" has a concrete, technical answer: row-level isolation in the database plus a five-year audit trail.
• Groups and chains — because the boundaries between companies are enforced by the database, not by an internal policy document.
• Anyone thinking about the exit — because the data lifecycle is closed: exports, self-service organisation deletion and GDPR-compliant data erasure.

A shared cloud, an autonomous building

Multi-tenant does not mean a site is hostage to the cloud. In building installations the role of the local node is played by Nextriv Hub Edge — an edge gateway that, alongside wireless sensors, reads RS485/Modbus, BACnet and KNX buses and executes control logic locally, even with the uplink down. The cloud remains the layer of supervision, analytics and multi-year history — shared infrastructure with private, isolated data — while the building reacts on the spot, independently of the internet.

How to verify this with any provider

To close, three questions worth asking any cloud monitoring provider: what technically — not contractually — isolates organisations' data? How long is the event log retained and does it cover administrators' actions? What happens to the data once the relationship ends? If the answers come without hesitation, the architecture was designed around boundaries rather than patched up after the fact. Nextriv's answers are in the pricing and live — during a platform demo, where we will also show what setting up an organisation from scratch looks like.