Multi Tenant SaaS Architecture

What multi tenancy changes in a SaaS product

A multi tenant product serves many customer organizations from one codebase and, usually, shared infrastructure. Each tenant has its own users, data, settings and often its own connections to outside systems. Getting that right means every query, background job, file, cache entry and log line knows which tenant it belongs to. Tepia treats tenant context as a first class part of the architecture rather than a column added later.

B2B products that connect to their customers’ business systems add another layer. Customer A syncs with QuickBooks Online, customer B with NetSuite, customer C with Salesforce and HubSpot. Each connection has its own credentials, field mappings, sync schedule and error history, and none of them can leak across tenants. A large share of Tepia’s SaaS work is designing that per tenant integration layer so new connectors can be added without touching the core.

Silo, pool or bridge: choosing an isolation model

Tepia walks every client through the three common models before writing code:

Tepia most often starts with the pool model on PostgreSQL, using row level security policies so the database itself rejects cross tenant reads, and designs the code so a tenant can later move to its own database. That keeps the early product simple while leaving a path for the enterprise customer whose security team insists on dedicated storage.

Carrying tenant context through every layer

Isolation fails at the edges, so Tepia checks each layer explicitly:

• Request entry: the tenant is resolved from the subdomain, custom domain or signed token at the edge, never from a value the browser can edit.
• Database: each connection sets the tenant before queries run, and row level security enforces it.
• Caches and files: cache keys and storage paths include the tenant ID, with storage policies to match.
• Background jobs: every job carries its tenant, so a nightly sync cannot run against the wrong account.
• Limits: per tenant rate limits and queue partitions stop one large customer from slowing everyone else.
• Observability: logs and metrics are tagged by tenant, so support can see one customer’s errors without searching through everyone’s.

Automated tests create two tenants and try to read across them through every API endpoint. Tepia runs those tests in CI on every change, as described on our QA and automated testing page.

Onboarding, offboarding and enterprise requests

Tenant lifecycle is where operations time disappears if it is manual. Tepia automates provisioning so a signed customer gets a tenant, default roles, sample data, a subdomain or custom domain with TLS, and an admin invite in one step. Enterprise tenants then connect their identity provider, covered on our SSO and identity integration page, and turn on SCIM.

The requests that follow are predictable: export all of our data, delete it when the contract ends, keep it in the EU, give us our own database, show us an audit log. Tepia builds each as a routine operation rather than an engineering project, including moving a tenant from the pool to a dedicated database with a short, scheduled switchover. The data model choices behind this are covered on our database design page.

Offboarding needs the same discipline in reverse. When a contract ends, Tepia’s tenant closure job revokes the customer’s OAuth connections to outside systems, disables its users, produces a final export, and schedules deletion of data and backups on the timeline your terms promise, logging each step so you can confirm it happened.

How Tepia approaches multi tenant SaaS architecture

1. Discovery: interviews about your customers, their size, security expectations and the systems they will connect, plus a review of any existing codebase. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a customer admin connecting their own NetSuite account.
2. Design: a tenancy model decision record, the data model, and wireframes for tenant admin, user management and integration settings, guided by a design questionnaire and style guide.
3. Development and Testing: an Alpha with internal test tenants and a Beta with a few friendly customers, with test plans for cross tenant isolation, load from a large tenant and user acceptance.
4. Training: sessions for your support and customer success teams on tenant setup, audited impersonation and data export requests.
5. Launch: migration of existing customers into tenants, DNS and certificate setup, and support reps on the rollout.
6. Support: issue resolution, bug tracking, scaling reviews as tenants grow, and feature requests such as a new connector.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month. Read about our process.

Retrofitting tenancy into an app built for one customer

A common starting point is an app built for one company that now has a second and third customer asking for it. Copying the codebase per customer works briefly, then every fix has to be applied several times. Tepia’s usual path is to add a tenant table and tenant ID to the data model, backfill existing records into the first tenant, turn on row level security table by table, and move settings that were hard coded for the first customer into tenant configuration.

The work happens behind the running app, so the original customer keeps working throughout. Our SaaS product development page covers the product side of that transition, and you can talk to Tepia about where your app stands today.

Frequently asked questions