Sooner or later, someone says the words: "We're going multi-tenant." Suddenly you're making a decision that will shape your data access layer, your deployment pipeline, and your on-call rotation for years, usually with about an afternoon to think it over.

There are three common answers, and they're often presented as a simple ladder from "cheap and messy" to "expensive and safe." That framing is wrong, and it often leads teams to the wrong choice. Every step up the isolation ladder actually deletes application code, from the global query filter to the TenantId column to the SaveChanges stamp. The tradeoff replaces it with operational complexity somewhere else. You don't buy safety with complexity. You move the complexity from your code to your infrastructure, and you'd better know which one your team is better at handling.

In this session, we'll build the same application three times. We'll start with a shared database using EF Core global query filters. Then we'll add SQL Server table partitioning so the database physically keeps each tenant's rows in their own drawer. Next, we'll move each tenant into its own schema and watch a surprising amount of code disappear, in exchange for exactly one new thing you have to get right. Finally we'll go all the way to a database per tenant, with a catalog database, connection-string routing, and the "joy" of running migrations against N databases on every single deploy.

Along the way we'll talk about the things that decide this for you in practice: compliance requirements, noisy-neighbor performance, tenant count and size distribution, cost per tenant, the "can we restore just one customer?" question, and what happens the day your biggest client asks to be moved somewhere else. You'll leave with a clear mental model of the trade-offs, working patterns for all three approaches, and a set of questions to ask before you commit , plus a frank look at what it takes to change your mind later.