Single Tenant vs Multi Tenancy: What Each Costs to Run

01The two models in one paragraph each

Single tenant: each customer runs their own copy of the application with its own database, often on its own server. Nothing is shared, so one customer can’t see another’s data even if the application has a bug. Most self-hosted business software works this way: Perfex CRM is installed once per company, and that company owns the whole installation.

Multi-tenant: one deployment serves every customer. Each customer is a tenant, and every tenant-owned row carries the tenant’s id. Omnitech CRM and this website’s platform both work this way: one codebase, one database, one release, with the application making sure each request only ever reaches its own tenant’s rows.

02Single tenant vs multi-tenant, side by side

03What single tenant cost in practice

Omnitech ran its CRM on Perfex, a single-tenant installation. The isolation was never the problem; the costs were the ones that come with owning an installation:

• Business rules lived in custom modules inside the installation (pricing and sales discount rules among them), so each one had to be carried through every upgrade of the base product.
• The permission model was whatever the base product shipped: visibility was baked into permission names (view, view_own, minimal_access), and changing that meant changing someone else’s code.
• A second company or workspace means a second installation to host, back up and upgrade, which is the model’s cost in general, not a Perfex quirk.

Omnitech CRM is its replacement: a multi-tenant system designed from the start, with its own permission model (how access control works there) and an idempotent import that moved the data across (the reconciliation).

04What multi-tenant cost in practice

Multi-tenant moved the cost from operations into code. On this website’s platform, which serves mmuzammilq.com and GrowBizNest from one database, that cost is concrete:

• Every tenant-owned table has a tenant column, and 45 models carry one trait that filters reads, stamps writes and throws when no tenant is bound.
• Queued jobs carry the tenant in their payload and restore it before they run.
• The page cache is keyed by host and invalidated per tenant, so one site’s publish never clears the other’s cache.
• A test suite checks each of those rules, because a weakened rule doesn’t fail loudly on its own.

In return, a fix ships to both sites in one deploy, and a new site is a seeder rather than a server. The isolation rule that makes it safe, failing closed rather than open, is compared across four platforms in multi-tenant isolation.

05The hybrid: shared by default, dedicated on request

The choice is not binary. A common end state is a multi-tenant application where most tenants share a database and a few, for contractual, regulatory or load reasons, get a dedicated database or deployment running the same code. AWS’s SaaS architecture guidance describes these as different deployment models within one SaaS product.

I have not run a hybrid in production, so I won’t claim its costs from experience. What I would insist on is the same thing that makes the shared model safe: the application resolves the tenant first and never falls back, so a tenant that moves to its own database is a change in where its connection points, not a change in how the code finds its data.

06How to choose

If you are deciding for an existing product, the Platform Change-Readiness Scorecard scores tenant isolation and fourteen other factors in about ten minutes. For a review of the decision with your own constraints, see SaaS architecture.