How Per-Customer Deployments Inflate Operating Costs
Shipping a B2B product as a separate server for each customer feels simple at first. But costs grow in step with your customer count. Branch the code to satisfy one client and you end up fixing the same bug in several branches. Every security patch has to be rolled out server by server.
Say you have 20 customers and each server takes 30 minutes to deploy and verify. That is 10 hours per patch. At four patches a month, you spend 40 hours on deployment alone. Add version drift across customers, and reproducing bugs and handling support tickets gets harder too.
Signs it is time to consider multi-tenancy:
Three Data Isolation Models
| Model | Isolation | Cost | Best for |
|-------|-----------|------|----------|
| Shared DB, shared schema (tenant_id) | Low | Lowest | Many small customers, fast growth |
| Schema per tenant | Medium | Medium | Tens to hundreds of tenants, per-customer backups |
| Database per tenant | High | Highest | Finance, public sector, contractual physical separation |
No single model is always right. A realistic setup runs most customers on a shared schema and gives only large, heavily regulated customers a dedicated database. With schema-per-tenant, remember that migration time grows with the number of tenants once you reach the thousands.
Enforcing Tenant Isolation in Code
The most common incident in a shared-schema system is a missing `WHERE tenant_id = ?` that exposes another customer's data. Relying on developers to remember it every time will not prevent this.
Two Lines of Defense
By default, RLS doesn't apply to the table owner. Either enable `FORCE ROW LEVEL SECURITY` or connect through a dedicated application role.
Boundaries Beyond the Database
Prefix cache keys with `tenant:{id}:`, split file storage by tenant path and access policy, and enforce tenant filters on search indexes. Teams often isolate the database and forget about the cache or file storage.
Handling Customer Differences Without Branching
Absorb customer requirements through configuration, not code branches.
Set a clear rule: if a request would help other customers, build it into the product. If only one customer needs it, handle it outside the core through APIs and webhooks. That keeps your core code clean.
Noisy Neighbors and Operations
When one tenant runs a huge spreadsheet import or a heavy report, other customers on the same resources slow down.
A Phased Migration Roadmap
Migrate to Multi-Tenancy with POLYGLOTSOFT
Through our subscription development model, POLYGLOTSOFT supports every stage: choosing an isolation model, RLS-based data protection, settings and feature-flag design, and migrating existing customers. There is no large upfront budget, and you can adjust the scope month by month. Send us a requirements document describing your current architecture and customer base, and we will review the best migration path with you.