Multi-tenant SaaS architecture: isolation, billing, AI features and scaling choices

This technical article is for CTOs, architects and senior engineers designing a SaaS product or reworking one that has outgrown its first design. Our SaaS platform engineering guide introduces the silo, pool and bridge tenancy models and the control plane; this article goes one level deeper into how isolation is enforced at each layer, how data is partitioned, how billing is wired, how AI features stay inside tenant boundaries and how the platform scales.

Context: tenants, users and deployments

Start by defining the tenant. In business-to-business SaaS, a tenant is usually a customer organization with many users; some customers need several tenants, for example separate subsidiaries or separate test and production environments. In business-to-consumer products, a tenant may be one person, a family or a group. Microsoft's Azure Architecture Center makes the point that this definition, and whether a tenancy model is acceptable to customers, is a commercial decision as much as a technical one.

Separate the logical tenant from the deployment that serves it. A deployment, sometimes called a stamp, is one set of infrastructure. Many tenants can share a deployment, or one tenant can have its own. Keeping a tenant-to-deployment map from the start lets you move tenants between deployments later without rewriting the application.

Isolation is decided per layer

The AWS whitepaper on SaaS tenant isolation strategies calls isolation fundamental to SaaS design and describes crossing a tenant boundary as a potentially unrecoverable event for the business. Microsoft describes isolation as a spectrum rather than a single switch. In practice, each layer gets its own answer:

A common and sensible result is a pooled application tier with isolated data for the tenants that need it. Microsoft calls splitting some components per tenant while sharing others horizontal partitioning; giving selected tenants a whole dedicated deployment is vertical partitioning.

Data partitioning options

For a pooled database, enforce isolation in the database itself, not only in application code. PostgreSQL's row security policies are one way: once enabled on a table, rows are hidden unless a policy allows them, so a query without a tenant filter returns nothing instead of everything. Two details matter. Policies must be enabled per table, and table owners, superusers and roles with the BYPASSRLS attribute bypass them by default. The application should therefore connect with a role that does not own the tables, or the tables should force row security, so that the policies also apply to the owner.

Billing and metering architecture

Billing in multi-tenant SaaS is a pipeline, not a single integration.

AI features: data isolation and model cost per tenant

Assistants, AI search and summaries read more tenant data in one request than most screens do, so they need the same boundaries enforced in the same place.

• Filter retrieval outside the prompt. The retrieval service applies the tenant and user permissions from the session context. A prompt instruction such as "only use this customer's data" is not isolation.
• Key every AI cache by tenant. Cached answers and embeddings without a tenant key can return one customer's content to another.
• Keep tenant data out of shared training. Do not fine-tune a shared model on one tenant's data, and choose model providers whose terms exclude training on your requests. Regulated tenants may need a region or a dedicated model deployment.
• Meter model cost per tenant. Tokens and calls vary widely between tenants; attribute them per feature and enforce limits through entitlements.
• Delete on offboarding. A departing tenant's embeddings, indexes and logged prompts go with its database rows.

Scaling choices

Plan the tenant migration path early: how a tenant's data moves from the shared database to its own, how traffic is switched, and how you verify the result. It is much easier to design than to invent under pressure when your largest customer asks for it.

Operations: releases, migrations and restores

• Release in rings. Roll out to internal tenants, then a small share of customers, then everyone, with per-tenant feature flags.
• Automate schema migrations across the fleet. With schema-per-tenant or database-per-tenant, one release means many migrations; track which tenant is on which version.
• Restore one tenant, not only the whole platform. Customers will ask for a single tenant's data to be restored; test it before they do.
• Measure cost per tenant. Combine metering with the cloud bill to see which tenants and plans cover their costs.

Test evidence: what to test

These are general engineering practices, not results from a specific project:

• Cross-tenant access tests. Automated tests for every endpoint and job that try to read or change another tenant's data and must fail.
• Row-policy tests. Queries run without a tenant context must return no rows, including under the application's database role.
• Noisy-neighbour load tests. One tenant generates heavy load while response times for the others are measured.
• Single-tenant restore tests. Restore one tenant from backup into a clean environment and compare the records.
• Metering tests. Replayed and duplicated events must produce the same usage totals.
• Cross-tenant AI tests. An assistant asked about another tenant's records must find nothing, including through cached answers.

Example: Printcart

Printcart, one of the five Netbase Business Divisions, is a web-to-print and print-on-demand platform that turns online orders into print-ready files and routed fulfillment. It runs on a merchant's own store or as Shopify, Wix and WooCommerce apps, with setup in about 7 days, and reports 10,000+ partners over 10 years of service. Serving that many merchants from one product is the multi-tenant problem this article describes: each merchant needs its own catalog, orders and store connection on a shared platform. The Printcart portfolio record covers what Netbase engineered and operates, and printing and packaging shows the sector context.

Outside its own products, Netbase has worked since 2020 as the offshore development and managing partner on a multi-tenant cloud ERP for a US client that is not named, sold as SaaS to small and mid-sized businesses.

How Netbase approaches multi-tenant builds

Netbase works with AWS, Google Cloud, DigitalOcean and Cloudflare; no cloud partner tier or cloud certification is claimed. Typical timelines are 8 to 12 weeks for a SaaS MVP, 3 to 6 months for a mid-tier product and 6 to 12 months or more for an enterprise platform, depending on scope; these are ranges, not quotes. Security is designed in from the first sprint: secure code review, TLS in transit and AES at rest, role-based access control, MFA for admin dashboards, vulnerability scanning and disaster recovery planning. AI models are chosen per product, not tied to one vendor. The SaaS development service builds the product, and the SaaS product accelerator starts from reusable modules for accounts, tenants, roles and billing.

Limits of this article

• It describes common patterns and general practice; the right mix depends on your tenants, data, regions and customers' contracts.
• The AWS whitepaper cited is marked as historical reference by AWS; its isolation principles remain widely used, but check current AWS guidance for service specifics.
• PostgreSQL is used as one example of database-enforced isolation; other databases offer different mechanisms.
• Timelines are typical ranges. Printcart is described from its published product information; no performance metric is claimed for it here.

Next step

Share your tenant profile, data sensitivity and pricing model, and we will book a solution review to choose the isolation and billing design for your first release. You can also see the related service or browse more Netbase insights.

Related services and solutions