Last updated: October 2026 · Tenancy models, trade-offs and pricing
Multi-tenancy sounds like a feature. In practice it is a decision that shapes your database, your billing, your support process and your hosting bill for years. I'm Arun Tyagi, a Laravel engineer in Sector 58, Noida, and I have built tenant-aware products where that decision was made well, and rescued a few where it was not.
This page is a deep-dive for founders and technical leads who need to choose a tenancy model. If you are already sure and want a build quote, jump to Laravel SaaS development.
Choosing a tenancy model?
Send your customer profile and expected data volume. A thirty-minute call usually settles it.
The three models
| Model | How it works | Best for | Pain point |
|---|---|---|---|
| Single database, tenant_id column | All customers share tables, rows scoped by tenant | Most early SaaS | One missing scope leaks data |
| Database per tenant | Each customer gets their own database | Compliance, large enterprise clients | Migrations across hundreds of databases |
| Schema per tenant | One database, separate schemas | PostgreSQL shops | Tooling is thinner |
My default recommendation
For most startups, a single database with a tenant_id on every tenant-owned table, enforced by a global scope and tested aggressively. It is cheap, simple to back up and easy to reason about. Move to database-per-tenant only when a customer or regulation demands it. That move is possible later if the code is disciplined now.
Where tenancy goes wrong
- Forgotten scopes. A raw query or a report that skips the tenant filter exposes someone else's data.
- Queues without context. A job runs after the request ends and has no idea which tenant it belongs to.
- Shared caches. Cache keys that omit the tenant mix customers.
- File storage. Uploads dumped in one folder with guessable paths.
- Billing drift. Plans, trials and usage limits tied to the wrong entity, tenant versus user.
What I build into a tenant-aware Laravel app
- Tenant resolution by subdomain or custom domain.
- Global scopes, plus tests that try to read across tenants and must fail.
- Tenant-aware queues, mail, cache and storage.
- Roles and permissions per tenant, with an owner, admin and member model.
- Subscriptions with Stripe or Razorpay, including trials, upgrades and failed payments.
- A Filament super-admin for your support team, with safe impersonation.
Pricing
| Scope | INR range |
|---|---|
| Tenancy layer added to an existing app | Rs.60,000–Rs.1,50,000 |
| Lean multi-tenant SaaS MVP | Rs.1,20,000–Rs.4,50,000 |
| Architecture review and plan | Rs.3,000 per hour |
The cost driver is rarely tenancy itself. It is billing complexity, integrations and how many roles you need.
FAQ
Should I use a package like Tenancy for Laravel?
Sometimes. Packages save time for database-per-tenant setups. For a shared database I often prefer a small in-house scope, so there is less to learn and nothing hidden.
Can I switch models later?
Yes, but it is a migration project, not a weekend task. Plan the boundaries now.
Is this overkill for my first version?
If you only have one customer, maybe. If the plan is to sell the same product to many, build it in from the start. Retrofitting costs more.
See it applied
The PayBev case study shows role-heavy payment flows with admin oversight. For hiring, see hire a Laravel developer, or read the wider Laravel development page.
Ready to build? Go to Laravel SaaS development for scope and timelines, then WhatsApp your brief or book a call.