Multi-Tenant Architecture: Shared Schema vs Isolated Database, and When to Switch
The shared-schema-with-a-tenant-id approach that got you to your first hundred customers is not the same decision as your thousandth. Here is how we decide.
"We will fix it later" is a real financial decision with a real interest rate. Here is how we actually quantify it for clients.
Technical debt is usually discussed as a vague moral failing — "we were sloppy and now we are paying for it" — instead of what it actually is: a financing decision, made under time pressure, that trades a slower present for a more expensive future. Some of those trades are correct. The problem is almost nobody tracks which ones, so the debt compounds invisibly until a quarter arrives where it dominates the roadmap.
Not all shortcuts carry the same interest rate. A slightly ugly but isolated function costs almost nothing over time — it is contained, nobody else builds on top of its mess. A shortcut in a core data model, an authentication flow, or an API contract that other teams or customers now depend on compounds fast, because every new feature built adjacent to it inherits the constraint, and unwinding it later means coordinating a migration across everything that grew around it.
Scoring debt items on those three axes turns "we should really fix that someday" into a prioritized list a product owner can actually weigh against a new feature — which is the conversation that gets technical debt work funded instead of perpetually deprioritized.
The highest-leverage moment to address debt is not a dedicated "tech debt sprint" once a quarter — by then the interest has already compounded. It is the moment a new feature is about to be built directly on top of the shaky part. We budget the fix into that feature's estimate rather than treating debt paydown as a separate initiative competing for roadmap space; it almost never wins that competition on its own.
More from the same category.
The shared-schema-with-a-tenant-id approach that got you to your first hundred customers is not the same decision as your thousandth. Here is how we decide.
Usage-based pricing sells well on a pricing page. The metering, reconciliation and dispute-handling behind it is where most implementations quietly fail.
A hardcoded "admin" and "member" role gets you to your first enterprise deal. It does not survive contact with their security questionnaire.
Thirty minutes with the people who would actually do the work — no discovery deck, no account manager.