Multi-Tenancy Architecture: Patterns, Isolation and Analytics

Multi-tenancy architecture is a design where one application and its infrastructure serve many customers, called tenants, while each tenant sees only its own data. IBM describes a tenant as typically a group of users, such as a customer organisation, served by a single instance of the software. The hard part is not sharing the servers. It is proving that tenant A can never read tenant B’s rows, in the app, the database and the dashboards you show customers.

This guide covers the three main data patterns, how to isolate tenants, what to test, and how analytics fits in. We build dashboards for SaaS teams, so we also cover the awkward bit most guides skip: tenant-level analytics.

dashrendrapp.dashrendr.comBring Tenant Analytics Into Your ProductBuild customisable dashboards from connected data or your REST API, then embed them so SaaS customers see their own data.Try the playground

TL;DR

• Multi-tenancy means tenants share some or all resources. Silo, bridge and pool are the three common database patterns, trading isolation against cost.
• Isolation is its own mechanism, separate from login and permissions. It has to be enforced on every path that touches tenant data, including reports and dashboards.
• Most SaaS products mix patterns. Shared compute with tenant-specific storage is common, and tiers can differ.
• Test isolation from the outside, with a tenant-scoped role, and put the tests in CI.
• dashrendr is an analytics platform for SaaS teams. Plans start at $6/month, with a 14-day free trial and no credit card required.

Table of Contents

• What multi-tenancy architecture actually means
• Silo, bridge and pool: the three data models
• How tenant isolation works in practice
• Testing and monitoring tenant boundaries
• Where multi-tenant analytics fits
• Our perspective
• Putting tenant dashboards in front of customers with dashrendr
• Mistakes we see most often
• FAQ
• Sources

What multi-tenancy architecture actually means

A tenant is a customer organisation, not a single user. Multi-tenancy describes how tenants share resources. AWS frames it as tenants being managed and operated collectively, where resources may be shared or dedicated. It also makes a point worth remembering: SaaS is more of a business model than an architecture strategy. Selling subscriptions does not tell you how your database is laid out.

The usual reasons to share are cost and operations. OWASP notes that serving many customers from shared infrastructure, code and often databases supports cost efficiency and simpler operations. The same sentence carries the catch: tenant isolation becomes a critical security requirement.

Single-tenant is the opposite end. Each customer gets its own deployment. It is easy to reason about and expensive to run, because you patch, monitor and upgrade every copy.

The four building blocks

AWS lists four building blocks of a multi-tenant SaaS architecture:

1. Tenant identity: every request carries a verified tenant context.
2. Data isolation: storage is partitioned so one tenant cannot reach another’s data.
3. Compute and runtime: shared or dedicated processing, with limits on how much one tenant can consume.
4. Operations: onboarding, monitoring and deployment that work per tenant and across all of them.

If you are early, identity is where to start. Everything else depends on knowing, reliably, which tenant a request belongs to.

Silo, bridge and pool: the three data models

The AWS guidance for multi-tenant architectures names three database-tier models. Here they are side by side.

Model	How it works	Isolation	Cost and complexity
Silo	Dedicated application stack and database per tenant	Strongest	Highest
Bridge	Shared application stack and database instance, dedicated schema per tenant	Middle	Middle
Pool	Shared stack, instance and tables, with row-level security separating tenants	Weakest by default	Lowest

Silo is the model for tenants who contractually demand their own environment. Pool is how most early-stage products start, because one schema is one migration. Bridge sits between them: one database server, but each tenant has its own set of tables.

You do not have to pick one

AWS points out that different services in one product can use different tenancy patterns: shared compute and storage, shared compute with tenant-specific storage, or tenant-specific compute with shared storage. Noisy-neighbour risk, pricing tiers and isolation needs all vary. A common split is a pooled model for small plans and a silo for an enterprise customer who asks for it.

A rough way to choose

• Many small tenants, cost-sensitive: pool, with strict row-level policies and good tests.
• A few large tenants with compliance demands: silo, or bridge at minimum.
• A mix of both: pool by default, with an upgrade path to dedicated resources for premium tiers.

IBM puts the tension plainly: developers must balance customers’ data-isolation needs against a design that scales quickly and affordably as traffic grows. There is no model that wins on both.

How tenant isolation works in practice

Authentication says who you are. Authorisation says what you may do. Tenant isolation, as AWS defines it, is a separate set of explicit mechanisms that tightly control access to resources and block cross-tenant access. A user can be fully authenticated and authorised in their own tenant and still hit another tenant’s data through a bug. Isolation is the layer that stops that.

OWASP says tenant data can be isolated with separate databases, separate schemas, or shared tables with row-level policies, or a hybrid, chosen on security, compliance, operational and cost needs. It also says tenant context must be verified and enforced across every tenant-owned access path. “Every path” is where teams slip: the main API is locked down, but an export job, a background worker or a reporting query is not.

Row-level security in PostgreSQL

For pooled models on PostgreSQL, row-level security (RLS) restricts which rows a query can see, based on the current user or a runtime variable. The PostgreSQL documentation describes CREATE POLICY as the command that defines a row-level security policy for a table. The rule of thumb is simple: the database enforces the filter, so a forgotten WHERE clause in application code does not leak data.

For shared-table designs, OWASP asks for four things: enforceable tenant ownership on every row, complete policy coverage, constrained request roles, and negative-path testing. We cover the mechanics in our piece on row-level security for dashboards, and in a longer look at tenant data isolation in shared databases.

Noisy neighbours are an isolation problem too

Isolation is not only about reads. One tenant running a heavy report can slow everyone else. AWS guidance on pooled deployments says effective isolation needs throttling at shared layers, and the example given there is agent workloads, but the principle carries to any shared API or query layer. Tenant-aware rate limits are cheap insurance.

Testing and monitoring tenant boundaries

OWASP’s guidance is to test through the same request role and connection path your application uses, not as a database superuser. A superuser bypasses the policies you are trying to verify. The checklist from the multi-tenant cheat sheet:

• Confirm cross-tenant operations are denied, not just that your own tenant’s operations succeed.
• Check RLS coverage on every table that holds tenant data, including new ones.
• Check that tenant context is reset properly on reused connections, so a pooled connection does not carry the last tenant’s identity.
• Apply tenant-aware rate limits on shared resources.

A concrete test from OWASP’s authorization regression guidance: run broad read queries as one tenant and confirm none of another tenant’s data comes back. The same guidance recommends running these tests in CI/CD so a build fails if a change leaks cross-tenant data.

The stakes are the reason to bother. OWASP warns that a single vulnerability can expose every tenant’s data, and a misconfiguration can leak across boundaries. In a silo, a bug exposes one customer. In a pool, it can expose all of them.

Where multi-tenant analytics fits

Analytics is the part of a multi-tenant product that is easiest to get wrong, because dashboards query a lot of data and are often built after the core app. Two separate jobs hide under the word.

Customer-facing analytics. Each customer sees charts of its own data inside your product. Here the isolation rules above apply directly: the dashboard must only ever query that tenant’s rows. Our guide to multi-tenant dashboards and data isolation walks through how that works, and the three architecture patterns for embedded analytics compares the build options.

Tenant-level metrics for your own team. The AWS SaaS Lens recommends capturing tenant-level insight into feature use, resource consumption, system health and tenant cost. Per AWS, these insights help you assess scaling, understand feature use and shape business and architectural strategy. AWS also separates metering, which is data for billing, from metrics, which is data for business and operational analysis. You need both, and they usually live in different tables.

Practical consequences:

• Keep a tenant ID on every analytics table, not just the transactional ones.
• Decide which dashboards are tenant-scoped and which are cross-tenant admin views. Never reuse one for the other.
• Treat scheduled email reports as another access path. A report sent to a customer must be scoped to that customer exactly as the live dashboard is.
• Pick metrics customers care about. We list five metrics worth showing customers.

Our perspective

We get asked a version of the same question a lot: should we build tenant dashboards ourselves? Our honest answer is that a chart library gets you charts in an afternoon, and then the real work starts. Layouts, per-tenant security, exports, scheduled emails and branding all land on your team. At the other end, enterprise BI tools are built for analysts, cost $1,000+ per month in the cases we compare against, and take real effort to set up.

We built dashrendr for the gap in between. It is an analytics platform for SaaS teams: connect your data sources or push data through the REST API, build dashboards in a drag-and-drop editor, then embed them in your product, use them internally, or email them on a schedule.

Our view on isolation is that you should pick your tenancy model first, on its own merits, and then make sure your analytics layer respects it, not the other way around. Whatever you choose, test it from the outside as a tenant would.

— Paloma

Putting tenant dashboards in front of customers with dashrendr

dashrendr plans start at $6/month. The published tiers are Hobby at $6 per month, Starter at $15, Grow at $39 and Premium at $99, and extra team members are $3 per month each. The plans differ by number of dashboards, team members, white-labelling and feature access. There is a 14-day free trial, and no credit card is required to start.

If you are comparing options, start with the pricing page and work out which tier covers your dashboard count. dashrendr supports multi-tenant security, white-label portals for branded customer views, and automated reports delivered by email. Data comes from sources such as PostgreSQL, MySQL, BigQuery, MongoDB, Google Sheets and Google Analytics, listed under data integrations. If your data is in Postgres, see how to build a SaaS metrics dashboard on PostgreSQL.

The same dashboards work internally too, for operations and support teams tracking their own KPIs.

Mistakes we see most often

• Filtering in the UI only. Hiding other tenants’ data in the front end is not isolation. The query itself must be scoped.
• Forgetting the side doors. Exports, webhooks, background jobs and scheduled reports need the same tenant context as the main API.
• Testing as an admin. Admin roles bypass policies, so the tests pass and prove nothing.
• Locking into one pattern. Plan for a premium tier that gets dedicated resources, even if you start pooled.
• Ignoring cost in the analytics warehouse. Per-tenant dashboards can multiply queries. Our note on BigQuery cost optimisation for SaaS dashboards covers one common case.

FAQ

What is the difference between single-tenant and multi-tenant architecture?

In single-tenant, each customer gets a separate deployment of the application and database. In multi-tenant, one instance serves many customers and keeps their data apart through logical controls. Multi-tenant is cheaper to run and easier to update, while single-tenant gives simpler isolation at higher cost.

Which multi-tenant database model should I choose?

It depends on your tenant count and isolation requirements. AWS describes silo, bridge and pool, with silo isolating most and costing most, and pool the reverse. Many teams start with pool and offer dedicated resources to larger customers later.

Is row-level security enough to isolate tenants?

It is a strong control for pooled databases, but not the whole answer. OWASP also asks for full policy coverage, constrained request roles and negative-path tests. Without those, a policy gap on one table can still leak data.

How do I keep customer dashboards secure in a multi-tenant app?

Scope every dashboard query to the tenant on the server side, and apply the same scoping to exports and scheduled emails. Then test with a tenant-level role to confirm that another tenant’s data is refused. Our dashboard isolation guide goes through the steps.

Sources

• What Is Multi-Tenant? | IBM
• Re-defining multi-tenancy, AWS SaaS Architecture Fundamentals
• Multi Tenant Security, OWASP Cheat Sheet Series
• Multi-tenant SaaS architecture: 4 building blocks, AWS
• Guidance for Multi-Tenant Architectures on AWS
• SaaS Architecture Fundamentals, AWS Whitepaper
• AWS Prescriptive Guidance: managed PostgreSQL multi-tenancy
• PostgreSQL documentation: CREATE POLICY
• AGENTPERF07-BP02, AWS Well-Architected
• Authorization Regression Testing, OWASP Cheat Sheet Series
• SaaS Lens, AWS Well-Architected Framework

Recommended

• Multi-Tenant Dashboards: Data Isolation Guide
• Tenant Data Isolation in Shared Databases
• SaaS Analytics Architecture: 3 Patterns Compared
• Self-Serve Analytics: How-To Guide for SaaS