A bigger customer's security review asks 3 things about tenancy: can one customer's users ever read another customer's data, who reads the audit log, and can the data stay in the EU. If the honest answer is a filter somewhere in the application code, the deal waits.
A good multi-tenant SaaS architecture answers those questions with mechanisms you can show. A full review has 5 tenancy questions, and the database model answers only one of them. The other 4 decide whether the review passes.
We met this on CondoGenie. Its first version, GeniePad, ran a single condominium building in 2009. We rebuilt it as a multi-tenant SaaS starting in 2018, and today one codebase runs over 550 condominium and HOA associations and over 80,000 registered users (admin panel, October 2026).
The same 5 questions show you what a good architecture contains, and how to judge whoever builds yours.
TL;DR: A good multi-tenant SaaS architecture answers the 5 tenancy questions in a customer's security review with mechanisms you can show. Start on a shared database with Postgres row-level security, and plan the move to schema- or database-per-tenant before a contract forces it. Judge whoever builds it by the tenant models and isolation tests from projects they've delivered.
What multi-tenant SaaS architecture means
Multi-tenant SaaS architecture is a design where one running application, and usually one database, serves many customers (tenants). Each tenant sees only its own data, users, and settings. Software enforces that separation, so one release reaches every customer at once.
Single-tenant is the opposite: a separate deployment for each customer. It isolates by construction and multiplies every upgrade, backup, and on-call shift by the number of customers.
Each product defines what a tenant is. In CondoGenie a tenant comes in 3 levels: an account, a management company that administers many accounts, and the super admin who runs the platform. An account is one condominium or a group of buildings under one legal entity.
The tenancy questions a good multi-tenant architecture answers
Each of the 5 tenancy questions in a security review needs a mechanism. The table pairs each question with the mechanism that answers it and the project where we built it.
| Question the review asks | Mechanism that answers it | Where we built it |
|---|---|---|
| What is a tenant in your product? | A written tenant model (account, organization, or workspace) | CondoGenie (with per-tenant subdomains), Adact, EveryPig |
| Where does the system enforce isolation? | Below the application: row-level security or a separate schema or database, plus a server-side check on every request | An HR tech client, a multi-tenant AI agent SaaS |
| How do roles stay inside a tenant? | Roles scoped to one tenant, never global | EveryPig, a healthtech client |
| What does the audit log record, and who reads it? | A per-tenant audit log that also records support staff entering a customer account | A multi-tenant AI agent SaaS |
| How do you move or restore one tenant? | Per-tenant export and restore, and a path to move one tenant to its own database | CondoGenie (9 years of data migrated while the business stayed live) |
Roles trip up more teams than databases do. The AWS SaaS Architecture Fundamentals whitepaper states that a user can pass authentication and authorization and still reach another tenant's resources, because isolation is a separate layer from login and permissions.
Restoring one tenant is the question teams skip. In Atlassian's April 2022 outage, a script deleted 883 sites belonging to 775 customers. Each data store held many customers' data, so engineers restored individual pieces from backups by hand, as Sri Viswanath wrote in the post-incident review.
Start on a shared pool and move to a silo when a contract demands it
Start a new B2B SaaS on a shared database: a tenant_id column on every table and Postgres row-level security (RLS), a database rule that filters every query to the current tenant's rows. Move a tenant to its own schema or database when a contract or a regulator asks for it, and price that move.
| Shared pool (RLS) | Schema-per-tenant | Database-per-tenant | |
|---|---|---|---|
| Isolation | Logical, enforced by the database | Logical, separate namespaces | Physical |
| Cost per tenant | Lowest | Medium | Highest |
| Schema migrations | Run once | Run per tenant | Run per tenant, per database |
| Per-tenant customization | Limited | Columns and indexes per tenant | Anything |
| Move here when | You're starting | A customer needs its own structure | A contract or regulator requires physical separation |
Manveer Chawla of ClickHouse calls the shared schema "the best default for most new B2B SaaS platforms in 2026" in his multi-tenant Postgres guide. Our HR tech client's platform isolates tenants this way, with RLS on PostgreSQL 16.
Schema-per-tenant and database-per-tenant charge you in migrations. One developer on Laracasts worked out that a 5-second migration run across 1,000 tenant databases takes more than 83 minutes. ClickHouse's guide also warns that schema-per-tenant bloats the Postgres system catalog as tenants multiply.
The shared pool's own risk is the noisy neighbor: one tenant's heavy workload slowing everyone else. On Adact, we kept campaign configuration in PostgreSQL and game-session analytics in MongoDB, so heavy campaign traffic stays away from campaign setup. Our SaaS platform architecture decisions piece covers the trade-offs around it.
The Isolation Ladder: move a tenant up when its terms change
An isolation model picked once at launch meets its first test when a new contract asks for more: a residency clause, a questionnaire the shared pool can't answer, or one tenant's load you can't throttle. With the Isolation Ladder, that tenant moves up one rung on a trigger you named in advance, and every other tenant stays pooled on the same product version.
Start on the lowest rung that serves today's customers, and write down the trigger for each step up:
| Rung | Model | Trigger to climb |
|---|---|---|
| 1 | Shared pool with RLS | A customer's terms the pool can't meet: their own schema, an auditable logical boundary, or one tenant's load you can't throttle |
| 2 | Schema-per-tenant | A contract or regulator requiring a dedicated database, or a residency clause |
| 3 | Database-per-tenant | Enough dedicated tenants that running them one by one costs more than a tiered model |
| 4 | Mixed by tier | Pooled tenants and a priced dedicated tier, on one product version |
We've built tenant isolation across 5 builds. On the projects in this article, the push to change tenancy came from the business. CondoGenie had to serve many condominium associations where GeniePad served one building, and Revenue Boosters wanted a white-label version of its product to sell to other companies.
Rung 4 is long-standing cloud guidance. The AWS SaaS Lens describes a pooled Silver tier and a dedicated Premium tier at a higher price, often kept off the public pricing page and run on the same product version as the pool. Microsoft's Azure guidance agrees that you don't have to pick one extreme.
Where tenant isolation breaks in practice
OWASP's Top 10:2025 still ranks broken access control first, and found some form of it in 100% of the applications tested. In multi-tenant products it tends to break in 5 places:
- The database owner skips RLS: The PostgreSQL documentation says superusers and
BYPASSRLSroles always bypass row security, and table owners do too unless you setFORCE ROW LEVEL SECURITY. Connect the app as a role that owns nothing. - Views read everything: Lukas Fittl explains in pganalyze's guide to RLS bypasses that a Postgres view ignores RLS policies by default. Use security invoker views (Postgres 15 and later). RLS also changes query plans: Gwen Shapira of Nile said on Postgres.fm in June 2025 that "with RLS, there is basically no way to force the plan you want," so load-test tenant queries before launch.
- Tenant context leaks between requests: In Nile's multi-tenant RLS post, Miki Pokryvailo describes the RLS user ID sitting in thread-local storage while the server reused threads across requests. Set the tenant per transaction, and don't trust a connection pool to reset it.
- Tests never meet RLS: The same Nile team had to move its tests to an app user that doesn't bypass RLS. Test a cross-tenant read as the app role, and expect it to fail.
- The audit log leaks: In Sophos incident INC-2025-002, a logging error showed one tenant's audit log activity under another, across about 2,100 Sophos Fusion customers. The fix, released in April 2025, added validation checks and a tenant filter on the audit log view.
On our multi-tenant AI agent SaaS, any request for another workspace's agents, widgets, knowledge sources, or conversations returns 403 or 404. When a platform admin enters a customer workspace, the screen shows a banner and the session goes into the log. Our HR tech client's platform hides team results for groups under 7 people, because a small group's answers point to individuals.
What we built: multi-tenant mechanisms from 6 Brocoders projects
We name the mechanisms from 6 projects the way a security review names them.
| Mechanism | Project | What it does |
|---|---|---|
| 3 tenancy levels, per-tenant subdomains | CondoGenie | Accounts, management companies, and a super admin, with each condominium account on its own subdomain |
| Agency-to-client tenant hierarchy | Adact | Agencies run campaigns for their brand clients, and each account has an owner and team members |
| Configuration and analytics split | Adact | Campaign setup in PostgreSQL, game-session analytics in MongoDB |
| Tenant types with per-organization isolation | EveryPig | Pig farms and veterinary practices keep separate operational data on shared infrastructure |
| Row-level security, EU residency, erasure | An HR tech client | PostgreSQL 16 RLS, hosting in AWS Frankfurt, and anonymization for right-to-be-forgotten requests |
| Isolation at the database and API layers | A multi-tenant AI agent SaaS | Any cross-workspace request returns 403 or 404 |
| Audit log and logged support access | A multi-tenant AI agent SaaS | A platform admin session inside a workspace shows a banner, and the platform logs it |
| Tenant-scoped roles, branded subdomains | A healthtech client | Roles: Super Admin, Admin/Owner, and Agent. Auth0 with two-factor authentication. A subdomain per client organization |
| Billing per tenant | CondoGenie, a multi-tenant AI agent SaaS | CondoGenie: 4 subscription tiers on Stripe, Rotessa, and Xero. AI agent SaaS: credit caps with 80% and 100% alerts, and auto-disable on downgrade |
CondoGenie is the longest-running of these: 2018 to today, features grown from 6 at launch to 23, and over 550 associations on one codebase. Access control works at category level, with default groups for owners, administrators, board members, and residents.
Adact is a no-code platform for gamified marketing campaigns. On it, one agency ran a 10-day campaign that drew 567,077 landing-page visitors, 478,846 completed games, and 18,574 registrations.
"We've tested the product and acquired two million interactions without experiencing downtime or bug issues."
Kalev Kärpuk, CEO, Adact
On EveryPig, caregivers, veterinarians, and producers work as separate user types, and each organization assigns roles and access to its own team. The rest of the work is in our SaaS case studies.
Retrofitting multi-tenancy onto a live product: CondoGenie
Rafal Dyrda built GeniePad in 2009, while serving on his condo board, to run one building. Starting in 2018, we built a new multi-tenant codebase beside it, with the 3 tenancy levels above, per-tenant subdomains, and a new name.
We moved 9 years of GeniePad data run by run while the business stayed live, and we have upgraded the same codebase in place since.
In August 2026 an account arrived with 34 buildings registered at one street address, a shape the registration flow had never met. We unblocked it the same month.
Retrofitting tenancy onto a live single-tenant product is the most expensive rebuild we do: on CondoGenie, 18 months passed before the first release. We do this work as application modernization services, with customers on the product the whole time. Our guide on how to modernize without stopping the business covers the sequence, and the same retrofit comes first when you're turning an internal tool into SaaS.
The cheaper path is to decide tenancy the moment selling to a second company comes up. Revenue Boosters, whose route management platform we built from scratch, later wanted a white-label version to sell to other companies. That request is the trigger: settle the tenant model before the first white-label customer signs.
Questions to ask whoever builds your multi-tenant SaaS
A vendor's page can list RLS, role-based access control (RBAC), and audit logs without having built them. Ask for evidence from a delivered project, in 2 groups.
Tenant model and isolation
- Show the tenant model from a product you shipped: what a tenant is and how requests find it.
- Show where the system enforces isolation below the application, and which database role the app connects as.
- Show the test that proves a cross-tenant read fails when run as the application role.
Audit, restore, and support access
- Show what the audit log stores, who can read it, and how the product filters it by tenant.
- Explain how one tenant moves to its own database, and how you'd restore one tenant without touching the others.
- Explain how support staff enter a customer account, and how the system logs that access.
These are the questions we answer with the projects above. If you already run a SaaS, start with a Code and Architecture Audit. It's a standalone product: if the answer is that you shouldn't rebuild, we write that down, and you keep every artifact either way.
If you're starting a new product, start with Solution Design, where we decide tenancy and billing before the first module. Both are part of our SaaS development services.
Decide the tenant boundary before a customer asks
The 5 questions arrive with your biggest prospect, ready or not. Answer them with a shared pool and RLS today, a named trigger for each rung of the Isolation Ladder, and an audit log that stays inside each tenant.
If your product already has customers and tenancy is the open question, book a Code and Architecture Audit with our SaaS development team. You'll get a written answer on what to change and what to keep.
Frequently Asked Questions
It's a design where one running application, and usually one database, serves many customers, called tenants. Each tenant sees only its own data, users, and settings, and software enforces the separation. CondoGenie runs over 550 condominium and HOA associations this way on one codebase.
Start with a shared database, a tenant_id column on every table, and Postgres row-level security. It's the cheapest to run, and you migrate the schema once. Move a tenant to its own schema when it needs its own structure, and to its own database when a contract or regulator requires physical separation.
It's one tenant's heavy workload slowing every other tenant on shared infrastructure. Fixes include per-tenant rate limits, separating heavy workloads, and moving a large tenant to dedicated resources. On Adact, game analytics run in MongoDB, apart from campaign configuration in PostgreSQL, for exactly that reason.
Row-level security covers the database layer only, and it needs an application role that doesn't own the tables or hold BYPASSRLS. It also needs security invoker views, tenant context set per transaction, and tests that run as the app role. Add a server-side check on every API request: on our multi-tenant AI agent SaaS, a cross-workspace request returns 403 or 404.
Scope role-based access control (RBAC) to one tenant, so an admin in one customer account has no rights in another. The audit log records actor, tenant, and action, filters by tenant when customers read it, and logs every support session inside a customer account.
Single-tenant makes sense when a contract, a regulator, or a data residency clause requires a dedicated deployment for one customer. Offer it as a priced tier on the same product version, so you still run one codebase. For a product sold to small and mid-sized businesses, it adds cost without isolation anyone asked for.
Look for a team that can show a tenant model, isolation enforced below the application, a passing cross-tenant test, and an audit log from a project it delivered. Brocoders' multi-tenant builds include CondoGenie in proptech, Adact in martech, and EveryPig in agritech. We have also built healthtech, HR tech, and AI agent platforms.