Multi-Tenant SaaS Architecture: Decisions You Cannot Undo Later

Most founders building SaaS don’t think about multi-tenancy until they’ve already written code. That’s expensive. The architecture choice you make in week two determines whether you can scale to 500 customers or hit a wall at 50. And unlike other technical decisions, this one is genuinely difficult to reverse without a rewrite.

We’ve worked with Australian startups trying to bolt multi-tenancy onto single-tenant systems, and it’s brutal. You’re not adding a feature-you’re rebuilding your entire database, auth, and isolation layer while keeping customers live. We’ve seen this consume 4-6 months of development time and AUD$150k+ in unexpected costs.

If you’re planning a SaaS product, you need to make this choice now, with full knowledge of the trade-offs. Here’s what matters.

Database Isolation: The Three Models

There are three ways to isolate customer data in a multi-tenant system: separate databases, separate schemas, or row-level isolation within a shared database. Each has hard trade-offs.

1. Separate Database Per Tenant – Each customer gets their own database instance. Highest isolation, easiest to understand, simplest to debug. You pay for database overhead per customer (roughly AUD$50-150/month per small instance). Backups, migrations, and patching scale with customer count. Popular with enterprise SaaS where per-customer cost isn’t an issue.
2. Separate Schema (Same Database) – One database, multiple schemas (PostgreSQL calls them schemas; MySQL uses multiple databases, same concept). You get good isolation without per-instance costs. Migrations get tricky-you run the same schema change across dozens or hundreds of schemas. Most teams use tools like Flyway or Liquibase to automate this. Scales to hundreds of customers without major pain.
3. Row-Level Isolation (Shared Schema) – One database, one schema, all tenants mixed. A tenant_id column on every table. Cheapest operationally. Most dangerous. A single buggy query can leak one customer’s data into another’s. You must enforce tenant_id in every query, everywhere. One missing WHERE clause becomes a security incident. This works if you have very tight quality control and small teams. It doesn’t scale to paranoid enterprise customers.

Most Australian SaaS we see starts with shared schema and regrets it within 12 months. The cost savings (maybe AUD$200/month) aren’t worth the compliance and security headaches later.

Our rough guidance: If you’re charging under AUD$500/month and targeting SMBs, start with shared schema but architect it as if you’ll move to separate schemas later (tenant_id in your domain models from day one). If you’re chasing mid-market or enterprise, use separate schemas from the start. If you’re building something where data isolation is a selling point (compliance software, healthcare), use separate databases-your customers will expect it, and you’ll charge enough to justify the cost.

Authentication and Subdomain Routing

The moment you go multi-tenant, you need to decide how customers log in and which instance they hit.

Single-subdomain (everyone at app.yoursite.com) means one auth system manages all tenants. Simpler to build. Hard to customise. Customers don’t get a branded experience. Common for horizontal tools (analytics, invoicing, project management).

Subdomain-per-tenant (acme.yoursite.com, globex.yoursite.com) lets you white-label and feels more enterprise. Auth becomes trickier-you have to identify the tenant from the subdomain, then route to the right database/schema. You’ll need wildcard DNS and a reverse proxy (Nginx, AWS ALB) that inspects the Host header and routes accordingly. Adds operational complexity. Worth it for enterprise or vertical SaaS where each customer feels like they own the platform.

Custom domains (acme.com) is a marketing feature, not a technical requirement, but it’s expensive to build right. You need SSL certificate management (wildcard certs or per-domain via Let’s Encrypt), DNS validation, and a way to handle certificate renewal across hundreds of domains. Most teams use dedicated services like Vercel or a custom certificate provider.

What matters operationally: Your routing layer must be fast and cacheable. A lookup that hits the database on every request will kill your performance at scale. Use in-memory caches (Redis) to store tenant-to-database mappings with a short TTL. Treat this layer as critical infrastructure.

Scaling and Data Blast Radius

Here’s the hard truth: once you have 200+ customers on shared schema, certain operations become dangerous. A schema migration that takes 30 minutes locks the entire database for all tenants. A data migration script that’s slightly off affects everyone simultaneously.

With separate schemas or databases, you can migrate one customer without touching others. A bug in a migration affects that customer only. Your blast radius shrinks dramatically.

This becomes critical around 500-1000 customers on shared infrastructure. Below that, shared schema is fine if you’re disciplined. Above that, you’re either moving to separate schemas or you’re managing technical debt.

We worked with a fintech startup that stayed on shared schema through 2000 customers. They’re now spending more on migration engineering than product development. Don’t do that.

Key trade-offs:

• Shared schema: Low operational cost, high risk on bad deployments, hard to scale beyond ~500 customers
• Separate schemas: Moderate cost, moderate complexity, scales to thousands
• Separate databases: High cost per customer, maximum safety, required for paranoid enterprise buyers

Resource Limits and Noisy Neighbour Problems

One customer’s misbehaving query can slow your entire platform if you’re on shared infrastructure.

A SaaS customer who imports 10 million records and forgets to add an index creates a full table scan. Their query takes 5 minutes. Every other customer’s requests queue behind it. Your system looks broken, even though only one tenant is behaving badly.

Separate databases isolate this completely. A misbehaving query only affects that customer. With shared schema, you need query timeouts, rate limiting, and resource quotas at the application layer. This is possible but requires discipline across your codebase.

For early-stage SaaS, shared schema with sensible defaults (query timeouts of 30 seconds, max connections per tenant) is usually enough. But build this into your architecture from day one. Don’t bolt it on when customers complain.

The Compliance and Audit Question

If your customers are regulated (finance, healthcare, security-conscious enterprises), they will ask about data segregation. Some will require it explicitly.

Shared schema with strong row-level isolation satisfies most compliance requirements on paper. But auditors and customers often feel better with separate schemas or databases. There’s no technical difference in security, but there’s a perception difference, and perception affects sales.

Enterprise SaaS companies often find themselves building separate databases not for technical reasons but for sales reasons. If you’re chasing that market, budget for it now rather than discovering it at the due diligence stage of a large deal.

If you’re building SMB-focused SaaS (marketing tools, scheduling software, invoicing), this doesn’t matter. Your customers don’t care. Save the infrastructure cost and build something better with the money.

What to Do Right Now

If you’re starting a SaaS product:

1. Decide on your tenant isolation model before you write code. Don’t default to shared schema because it’s easiest.
2. Design your domain model with tenant_id everywhere, even if you start with separate databases. Makes switching models later less painful.
3. Build a tenant context layer that every query runs through. Never have raw SQL that isn’t tenant-aware.
4. Test multi-tenancy early. Build a second test customer in your local environment. The earlier you catch isolation bugs, the cheaper they are to fix.
5. Plan your routing layer (subdomain, custom domain, or single-domain) before you launch. Changing it later requires rebranding.

These decisions compound. A wrong choice in week two costs you six figures and six months down the line. A right choice costs you a few extra days of thinking now.

If you’re serious about building a SaaS product and want to talk through the architecture decisions specific to your market and scale, talk to Amora about your build. We ship MVPs in 28 days, and architecture decisions are made in the first week. We’ve learned what works and what creates debt later.

Build it right the first time. The cost of fixing it wrong is too high.