Glossary / Multi-tenancy (tenant isolation)
An architecture where one software instance serves multiple customer organizations ("tenants") while keeping each tenant's data isolated from the others.
A multi-tenant SaaS platform runs one shared application and database for every customer, rather than a separate deployment per customer — which is what makes it economical to run and quick to onboard a new client, but it puts the isolation guarantee (one customer never sees another's data) at the center of the architecture.
Isolation can be enforced at different layers. The weakest version relies entirely on application code remembering to filter every query by tenant — one missed filter is a data leak. A stronger version enforces isolation at the database itself, so even a query that forgot to filter still can't return another tenant's rows.
For an MSP specifically, "tenant" usually means "client organization" — the platform an MSP runs is itself multi-tenant across every client it serves, which means the MSP's own platform vendor is making an isolation promise on behalf of every one of the MSP's clients, not just the MSP itself.
How Nexus handles this
Nexus enforces isolation at both layers — application-level scoping, plus PostgreSQL row-level security keyed per tenant at the database itself, so a bug in application code can't leak past it.
A company that remotely manages a client's IT infrastructure and end-user systems on an ongoing, proactive basis — usually a flat-fee contract, not break-fix billing.
Software that lets an MSP monitor device health and perform remote management tasks — patching, scripting, remote control — across every client site from one console.
Software that runs the business side of MSP operations — ticketing, SLAs, billing, contracts, and client records — the system of record most MSP work flows through.
Join the design-partner cohort and we'll show you exactly where this lives.