Multi-tenant SaaS sounds fancy, but the idea is simple. One app, many customers, and every customer feels like it's their own private system. The hard part is making sure that feeling is actually true, that one customer can never see, change or slow down another customer's stuff.
I've built a lot of these through Kordspace, across logistics, payments, music and AI. Some went smoothly. Some taught me lessons I'd rather not repeat. These are my working notes, the stuff I wish someone had handed me before my first one.
Think of it like an apartment building
The easiest way I've found to explain multi-tenancy is an apartment building. Every tenant has their own unit with their own locked door. They share the foundation, the plumbing and the electrical. The landlord keeps the building running, but they don't walk into your apartment.
In software terms: tenants share the servers, the code and usually the database. What they must never share is data or access. Every architectural choice you make is really a choice about how thick those walls are and who holds the keys.
Pick your isolation model early
There are three common ways to separate tenants, and switching later is painful, so decide on day one.
- ✦Shared tables, tenant column. Everyone's data lives in the same tables, and every row has a tenant ID. Cheapest and simplest to run. Also the easiest to get wrong if you forget a filter.
- ✦Schema per tenant. Each customer gets their own set of tables inside one database. Better separation, more complex migrations.
- ✦Database per tenant. Maximum isolation. Great for big enterprise customers who demand it. Expensive and heavy to operate at scale.
For most products I start with shared tables and a tenant column, and I let the database itself enforce the walls. I only move bigger customers to their own database if they truly need it. Starting heavy "just in case" is one of the most expensive mistakes I see.
Let the database guard the door
Here's the rule that has saved me more than any other: never trust the app alone to filter tenant data. Someday, someone, maybe me, will write a query and forget the tenant filter. If the only thing protecting your customers is every developer remembering every time, you will eventually leak data.
So I push that rule down into the database with row-level security. The database checks who's asking on every single read and write, and only returns rows that belong to them. Even a sloppy query can't cross the wall.
It's a bit more setup up front. It's also the difference between sleeping well and not.
Roles live in their own table
A related lesson: don't store someone's role, like "admin," on their profile where they might be able to edit it. Keep roles in a separate, protected table, and check them on the server or in the database. Never decide who's an admin in the browser alone. It sounds obvious, but I've reviewed more than one app where you could become an admin by editing a field.
Noisy neighbors are real
Isolation isn't only about data. It's also about performance. If one tenant runs a giant report, everyone else shouldn't feel it.
What helps:
- ✦Rate limits per tenant, not just per user.
- ✦Background jobs with fair queues, so one customer's big import doesn't block everyone's small ones.
- ✦Indexes that start with the tenant ID, so every query only scans that tenant's rows.
- ✦Watching the slowest queries per tenant, because the problem customer is rarely the one you'd guess.
I learned this one in logistics, where one warehouse importing a huge batch at month-end could slow down everybody's dashboards. Now fair scheduling is something I design in from the start.
Migrations without drama
Changing the database when hundreds of customers are using it live is where a lot of teams get burned. My rules:
- ✦Add, don't break. Add new columns instead of renaming. Backfill. Switch the code. Remove the old stuff much later, if ever.
- ✦Make every migration safe to run twice. Things fail halfway. You want to be able to just run it again.
- ✦Test against a copy of real-sized data. A migration that takes a second on your laptop can lock a table for ten minutes in production.
Logs that tell you whose problem it is
When something breaks in a multi-tenant system, the first question is always "who's affected?" If your logs don't include the tenant on every line, you'll waste the first hour of every incident just figuring that out. Put the tenant ID everywhere: logs, error reports, background jobs, analytics. Future you will be grateful.
Billing is part of the architecture
I used to treat billing as something you add at the end. Big mistake. Plans, limits and usage tracking touch everything: what features a tenant sees, how many seats they get, what happens when they stop paying. My payments work, including Tuzo Rewards, made it clear that billing logic needs a real home in the design, not a pile of if-statements sprinkled through the app.
Onboarding is a feature
The first ten minutes a new tenant spends in your product decide whether they stay. Creating a tenant should be fast, automatic and boring: set up their space, their first admin and sensible defaults in one go. If onboarding needs a developer to run a script, it will eventually become the thing everyone dreads.
Testing the walls
The last habit I want to share is the one people skip most: actually testing your isolation. It's not enough to believe tenants are separated. You should try to break it.
On every multi-tenant project now, I write tests that sign in as one tenant and deliberately try to read, update and delete another tenant's data through every route I can think of. Those tests should fail every single time. If one ever passes, I've found a leak before a customer did.
I also check what happens at the edges: a user who belongs to two tenants, an admin who gets removed mid-session, an invite link that's been forwarded to someone else. Real users find these paths quickly. It's much nicer if your test suite finds them first. A little paranoia here is the cheapest insurance you'll ever buy.
Keep the admin tools honest
One more thing: the internal tools your own team uses to support customers need the same care as the product. Support staff often need to look inside a tenant to help. Give them a clear, logged way to do it, ideally with the customer's permission, rather than a secret back door.
The takeaway
Make the safe thing the default, and make the unsafe thing hard.
Multi-tenant SaaS isn't about clever tricks. It's about strong, boring walls: the database enforcing who sees what, roles kept somewhere safe, fair sharing of resources and changes that never break the people already living in the building. Get those right and the product on top gets to be as fun and ambitious as you want.
If you're about to build one and want a second pair of eyes on the foundation, that's exactly the kind of thing I love talking through.