Multi-Tenant
Multi-tenant architecture lets a single SaaS system serve multiple separate organizations (tenants) on the same underlying infrastructure, while keeping their data completely isolated from one another. In StoreChart, tenant isolation is enforced at the database level using Row-Level Security (RLS).
Multi-tenant is an architecture in which one SaaS system serves multiple separate organizations ("tenants").
Each tenant experiences the system as if it were their own dedicated instance, but under the hood they all run on shared infrastructure.
In StoreChart, isolation is enforced at the Supabase Row-Level Security (RLS) layer — guaranteeing that every row in the database belongs to a specific tenant and is inaccessible to anyone else.
The alternative to multi-tenant is single-tenant architecture, where every customer gets a fully separate deployment (their own database, their own server resources). Single-tenant offers stronger physical isolation but is far more expensive to operate at scale, since infrastructure, updates, and maintenance need to be repeated per customer instead of shared. Multi-tenant SaaS makes the shared-infrastructure economics work specifically because isolation is enforced logically (through policies like RLS) rather than physically — which is why the strength of that logical enforcement is the single most important security property of any multi-tenant system.
The practical test of multi-tenancy done correctly is whether one tenant's data can ever leak, even accidentally, into another's queries — this is exactly what row-level security enforces at the database layer, so an application bug that forgets to filter by tenant still can't return another business's orders or customers. StoreChart relies on this database-enforced boundary rather than trusting every single query in the application code to remember the filter, which is the more common and more fragile approach in less careful multi-tenant systems.
The security value of true multi-tenancy is easiest to appreciate by imagining the alternative: a single shared database with an application-level 'if tenant_id matches' check scattered across every query, where a single missed check in one code path is all it takes for one business's data to leak into another's view.
Beyond security, multi-tenancy also determines how efficiently a platform can be operated at scale — a single well-maintained multi-tenant codebase serving thousands of businesses is far easier to patch, upgrade, and monitor than thousands of separate single-tenant deployments, each needing its own maintenance window and its own copy of every bug fix applied individually.
In short: multi-tenancy is an architecture choice, isolation is the security guarantee that architecture must deliver, and RLS is the specific database mechanism many modern platforms use to deliver it reliably.
Related terms
Multi-store means managing several online stores under a single system. Instead of running each store separately, all your data — orders, inventory, and customers — is synced and managed from one unified dashboard.
Row-Level Security (RLS) is a database security technology that ensures each row is accessible only to the correct user or tenant. In Supabase (and PostgreSQL databases generally), RLS is enforced at the database level — not the application level — which provides an additional layer of security.
Related StoreChart features
Frequently asked questions
Not inherently — a well-implemented multi-tenant system with database-level isolation (like RLS) can be as secure as single-tenant, since isolation is enforced by the database itself on every query rather than depending on developers remembering to filter correctly in application code.
Yes. Multi-tenant refers to data and infrastructure isolation, not feature uniformity — a system can still offer per-tenant configuration, branding, or feature flags while keeping every tenant's actual data completely separated at the database layer.
In a system relying only on application-level filtering, that bug could expose one tenant's data to another. In a system enforcing isolation with database-level Row-Level Security, the database itself blocks the cross-tenant query regardless of the application bug, which is why RLS is considered a stronger guarantee.