Tag: SaaS Architecture

A customer signs in to your SaaS product, opens a project, and downloads a file. Everything looks normal. The question behind SaaS tenant isolation is whether your system can keep that customer’s data separate throughout the journey—even if someone requests another customer’s project directly.

A login screen cannot answer that on its own. Neither can a separate database if a background worker later exports the wrong records. Isolation is the boundary that needs to hold wherever customer data goes.

Let’s make that less abstract. We’ll follow a fictional project-management product with two customer workspaces, then use it to compare architecture choices and decide what the team needs to test before release.

First, agree what a tenant actually is

In this example, a tenant is a customer workspace. Each workspace owns projects, files, and export history. A person can belong to more than one workspace, so “user” and “tenant” are different things.

That distinction matters as soon as someone switches workspaces. The application needs to know which workspace they are acting in, whether they still belong to it, and what they are allowed to do there. Knowing who logged in is only the beginning.

Imagine Maya belongs to workspace A. She asks the API for a project that belongs to workspace B. Even if she knows the project’s exact identifier, the application must reject the request unless a deliberate sharing rule gives her access.

That is the core promise to write down: ordinary workspace operations can only reach resources authorised for that workspace and person. If your product supports partners, shared projects, or customer-support access, describe those permissions explicitly too.

AWS’s explanation of tenant isolation is useful here because it separates identifying a user from keeping tenant resources apart. It also explains why a consistent enforcement mechanism matters: one forgotten check should not decide whether another customer’s records become visible.

Choose the boundary you need before choosing the database

Architecture discussions often jump straight to “one database or many?” A better opening question is: what do we need to separate, and why?

Keeping records confidential is one requirement. Preventing a large customer from exhausting shared resources is another. Restoring one customer’s data without changing everyone else’s is a third. A design can handle one well and still need work on the others.

For our project-management product, suppose many small customers use the same features. Sharing application servers and database tables could make provisioning and updates simpler. But if a customer requires a dedicated database, the team needs to explain exactly which boundary that adds and what remains shared.

These names describe an approach, not a universal security rating. Say which layer you mean. “Dedicated database, shared application servers” tells a reviewer more than “we use a silo model.”

The AWS PostgreSQL decision matrix compares more specific storage choices, including separate clusters, databases, schemas, and shared tables. It highlights the operating work around deployment, connections, and recovery as well as infrastructure cost.

Use those trade-offs to ask what your team can maintain. A fleet of separate databases still needs reliable permissions and upgrades. A shared database still needs a credible answer when a customer asks for an export, deletion, or restore.

Follow one request from the browser to the database

Maya opens a project in workspace A. The browser sends the project ID and the selected workspace. Treat both as a request for access, rather than evidence that access is allowed.

The server verifies Maya’s identity, confirms her current membership in A, and checks whether her role permits the requested action. It then looks up the project within that authorised context. If the project belongs to B, the request must not succeed.

This is object-level authorisation: permission to call an API does not automatically mean permission to access every object behind it. OWASP’s API security guidance explains this failure pattern and why checks belong wherever an endpoint accepts an object identifier.

The diagram follows that context through the system. The important part is the handoff: each service needs a trustworthy way to know which tenant is in scope and what the caller may do. A tenant ID copied from an untrusted header does not establish either.

Apply the same reasoning when creating or updating a project. The server should not accept a different tenant ID hidden in the request body simply because the person was allowed to edit a project. Both the existing resource and the proposed change need to stay within the authorised boundary.

Then consider a legitimate workspace switch. Maya might belong to both A and B, with different permissions in each. Selecting B should trigger the appropriate membership and role checks; it should not reuse A’s permissions because the person has stayed logged in.

Use row-level security carefully in a shared database

When customers share PostgreSQL tables, row-level security, or RLS, can help limit which rows a database role may read or change. Think of it as an additional rule at the data layer, closer to where a missing application filter could cause harm.

For the projects table, a policy can be designed around the trusted tenant context. The application still has to establish that context correctly. A database policy cannot tell whether an arbitrary workspace value supplied by a caller is legitimate.

There is also an important testing detail in the PostgreSQL row-security documentation: superusers and roles with BYPASSRLS bypass these policies, and table owners normally do as well. Test with the role the application actually uses, including the policy settings that apply to it.

A demo run under an administrator account can therefore give you the wrong impression. The useful question is whether the deployed application role receives the expected allowed and denied results.

Connection reuse deserves its own test. Database pools reuse connections across requests; tenant context must not leak from one request into the next. Review how your driver and pooler handle that context, including when a transaction fails.

RLS also does not give each customer independent compute or a separate recovery process. It solves a particular access-control problem. Keep the rest of the architecture decision visible rather than treating one feature as the whole isolation plan.

Keep the boundary intact when the request becomes a job or file

Now Maya clicks “Export projects.” The API queues work and responds before the file is ready. The original browser request is over, but the responsibility to keep customer data separate continues.

The worker needs a validated tenant scope and an authorised reason to produce that export. It should read only the intended records, store the output under the correct ownership, and deliver it through an access-controlled path. A global worker account should not turn an unchecked message field into authority.

File downloads raise a similar question. A tenant name in a storage path helps organise objects, but it is not proof that the requester may receive them. Check access to the file before issuing a download link, and choose the link’s scope and lifetime deliberately.

Next, look at the product’s shortcuts. Could a cached project response be reused for a person who should not see it? Could search reveal a document title from B even when opening the document is blocked? The boundary includes metadata and exports as well as the main project page.

This walkthrough often exposes a more useful design question than the database diagram alone: who owns each handoff? If the API team assumes the worker validates scope and the worker team assumes the API already did everything, write down the missing contract before release.

Test the design with two customers, not just one happy path

Create synthetic workspaces A and B, each with known projects and files. Add a member of A, a member of B, a person who belongs to both, and someone whose membership has been removed.

Known identifiers make the test stronger. Ask for B’s project while signed in as A’s member; submit B’s tenant ID in a write request; try the equivalent export and download paths. The goal is to establish whether the access rules hold, not whether identifiers are difficult to guess.

Then exercise the parts that share state: concurrent requests through the connection pool, repeated requests through the cache, and queued work that runs after a permission change. Decide what revocation should mean for outstanding jobs and previously issued download links.

The review workflow is a loop. Map a resource, identify the control, test it, and take any unexpected result back to the responsible owner. A failed check should change the design or implementation rather than disappear into a list of accepted assumptions.

Record successful access too. A system that blocks everyone has not met the product requirement. Your evidence should show that the right person can complete the right task while another tenant cannot.

The layers in this visual answer different questions. Application rules understand the action, database rules constrain data access, and operational processes govern the people and services with exceptional privileges. Review them together.

Bring nine clear answers to the architecture review

By this point, the team should be able to explain its choices without relying on “the framework handles it.” Use these questions to turn the discussion into something another engineer can inspect:

1. What is a tenant, and what sharing is intentional?
2. Which records, files, indexes, and exports belong to it?
3. Who establishes trusted user and tenant context?
4. Where is each read and write permission enforced?
5. Which database role runs the application?
6. What happens when connections and cached results are reused?
7. How do jobs and downloads preserve scope?
8. Who may cross the normal boundary for support or operations?
9. How are provisioning, revocation, and recovery tested?

Each answer needs an owner and evidence. That might be a policy review, a reproducible test, or a restore exercise. The exact artifact matters less than whether someone can check the claim.

If you are also building the wider quality plan, AppZime’s SaaS test-automation guide covers that related work. Keep isolation checks tied to the architecture instead of treating them as a final security test after the product is finished.

Choose a model your team can keep operating

The right design needs to work during a normal release, an incident, and a customer’s departure. Include tenant deletion, backup handling, and recovery in the decision—not only the cost of creating the first workspace.

A small team may have one person covering several responsibilities, but application logic, database policy, and access tests still need explicit ownership. When extra expertise is needed, define the gap: a backend engineer to carry context, a database specialist to review policies, or a QA engineer to maintain cross-tenant tests.

AppZime’s software development services and engineering staff augmentation support different delivery arrangements. Start a scoping conversation with your resource map and the unanswered questions, so the work has a clear purpose.

The result you want is straightforward: your team can follow a customer’s data through the product, explain the boundary at every step, and demonstrate that the boundary holds. That is a much stronger answer than the name of the database model alone.

Technical sources reviewed on 18 October 2026. The workspace example is fictional; implementation details depend on the selected platform and access model.