Multi-tenant SaaS: Data Isolation and Billing Models — How to Choose the Architecture

Why multi-tenant architecture is the cornerstone of SaaS

When a business launches a B2B platform, the questions of client data isolation and flexible monetization arise immediately. The choice of model — one database for all or a separate schema for each tenant — affects security, scalability, and the unit economics of the service. In this article, we'll break down the key approaches to isolation, their impact on billing, and suggest when to switch from shared to schema-per-tenant, based on the practice of developing SaaS applications.

Two poles of isolation: schema-per-tenant vs shared database

At the heart of multi-tenant architecture lies a compromise between ease of management and data isolation. Let's look at two classic approaches.

Shared database — a single schema for all

All clients store data in common tables, and record ownership is determined by a tenant_id field. This reduces deployment and update costs, but requires strict filtering at the query level and almost eliminates the possibility of customizing the schema for each customer.

• Minimal infrastructure costs — one database.
• Simplicity of CI/CD: one deployment updates the service for all.
• Risk: data leakage due to a query error without tenant_id.
• Complexity with analytics: separating metrics requires additional logic.

Schema-per-tenant — each client gets its own schema

When a new tenant registers, a separate schema in the database (e.g., PostgreSQL) or even a dedicated database is created. This provides almost physical isolation, simplifies backup, recovery, and compliance with requirements like GDPR. This approach is often used in products where clients require segregated data storage, for example, in CRM systems or financial services.

• Full isolation: queries within the schema do not need tenant_id.
• Easy scaling: "heavy" clients can be moved to separate servers.
• Individual migrations and schema updates for each tenant.
• Higher overhead costs for maintaining multiple schemas.

Hybrid scenarios and catalog-based isolation

In practice, "pure" shared or schema-per-tenant is rarely used. More often, a hybrid is used: a common database for shared reference data and separate schemas for critical data. Another compromise is the "catalog-based" approach: a common database server, but a separate database (catalog) for each client. This simplifies migration between shared and schema-per-tenant if a startup outgrows its monolith. When choosing an architecture, it's important to consider not only current MRR but also future growth, because online data migration in SaaS services with dozens of clients can halt the entire business. This is where the experience of teams designing cloud services with smooth scaling in mind comes in handy.

Billing models: how architecture dictates monetization

The data storage scheme directly affects how you bill. Let's examine three popular models and their connection to isolation.

Flat subscription

A fixed monthly price for access to the platform. This is easiest to implement with a shared database: all clients consume the same resources, and the load difference is averaged out. But if client traffic grows unevenly, you risk subsidizing "heavy" users at the expense of light ones. For such a model, minimal setup is often sufficient, which can be implemented even within a quick web development project.

Per-user or per-seat billing

The price depends on the number of active accounts or licenses. This is convenient with schema-per-tenant because you can easily count usage and isolate load at the client level. It works in CRM, document management systems, and other B2B services where value increases with the number of users. Often, this model is chosen for multifunctional corporate portals.

Usage-based billing

Metrics: number of API requests, volume of stored data, hours of usage. Requires detailed tracking at the transaction level, which is easier to implement in a schema-per-tenant model since the metric loads are not mixed. However, you can implement usage-based billing even in a shared architecture if you set up event aggregation by tenant_id. In any case, you'll need a reliable pipeline for collecting and billing events — this is one of the key modules when building SaaS applications.

What to pay attention to when choosing isolation and billing

• Security: if you work with financial, medical, or personal data, schema-per-tenant is almost mandatory for auditing and compliance.
• Operational costs: it's easier for a database administrator to maintain 10 schemas than 1000. Automating schema creation and removal is a mandatory part of the platform.
• Client onboarding: a shared database allows you to launch a pilot in hours; schema-per-tenant requires automated migration scripts.
• Customization: if clients need custom fields, reports, or integrations, a shared schema quickly becomes a patchwork quilt.
• Growth plan: if you plan to enter the US and EU markets, pre-establish the ability to physically separate data by region (data residency).

Frequently Asked Questions

Can you combine shared database and schema-per-tenant in the same product?

Yes, this is a common hybrid. For example, common reference data, templates, and data for machine learning are stored in a shared schema, while client orders, documents, and financials are isolated. This approach reduces overhead and maintains security for critical data.

Which billing model is more beneficial when starting a SaaS?

In the early stage, companies usually choose flat subscription or per-seat — they are simpler to implement and understandable to clients. Usage-based requires a more mature accounting infrastructure but allows for more precise monetization of value and attracts clients with smaller tickets.

How long does migration from shared to schema-per-tenant take?

It depends on the volume of data and the complexity of the service. In simple cases, a few weeks with full regression testing. For large B2B platforms with historical data, the process can take months, including stages of dual writing and gradual client migration. Therefore, it's better to make the architectural decision before launching the product.

Is Row-Level Security (RLS) sufficient for a shared database to pass a security audit?

RLS helps filter out other tenants' records at the database level, but for strict standards (PCI DSS, HIPAA) it often requires additional measures: access logging, data masking, administrator access control. Auditors may require physical separation, so RLS does not always replace schema-per-tenant.