Multi-Database
Krayin's Multi-Tenant SaaS comes in two flavours, and they differ in exactly one thing: where each tenant's data is stored. This guide documents the single-database edition — the one running at your platform. This page explains the multi-database edition, so you can tell which model you have and understand the trade-off.
What you'll learn
- The difference between the single-database and multi-database editions
- How the multi-database model isolates each tenant
- The advantages and the costs of a database per tenant
- Which model suits which kind of platform
Two ways to separate tenants
Every SaaS has to keep one tenant's data from leaking into another's. Krayin offers two ways to do it:
- Single-database (this guide) — one shared database. Every tenant-owned row carries a
company_id, and the platform limits every query to the signed-in tenant's own rows. Separation is enforced in software. See How It Works. - Multi-database — a separate database for every tenant. There's no shared table to leak from, because each tenant's data physically lives in its own database.
The super-admin experience is nearly identical either way — the same tenants, plans, subscriptions and cross-tenant views. What changes is what's happening underneath.
How multi-database works
A small central database holds the platform's own records — the list of tenants, the plans, invoices and settings. Each tenant then gets a database of its own, holding only their CRM data.
When a request comes in, the platform reads the address (acme.yourplatform.com), works out which tenant it belongs to, and connects to that tenant's database for the rest of the request. The super admin, meanwhile, works against the central database and can read across all the tenant databases for its platform-wide views.
The dashed line marks the super admin reading the central database; the solid lines show a tenant's request being routed to its own database.
What a tenant gets, either way
From the tenant's seat, the two editions feel the same: their own subdomain, their own CRM, their own team, and data no one else can see. A tenant never needs to know which model powers the platform. Everything in the Tenants section applies to both.
Advantages of a database per tenant
- Maximum isolation. There is no shared table, so one tenant's data can never appear in another's queries — separation is physical, not just enforced in code.
- Per-tenant backup and restore. You can back up, restore or migrate a single tenant without touching the others.
- Independent scaling. A heavy tenant can be moved to its own database server without affecting anyone else.
- Cleaner compliance. Data-residency and "delete all my data" requests are simpler when a tenant's data is a self-contained database.
Things to keep in mind
- More databases to run. Maintenance — upgrades, backups, monitoring — scales with the number of tenants, not with one shared database.
- Higher infrastructure cost. Many databases cost more to host than one.
- Slower sign-up. A new tenant's database has to be created and a full CRM installed into it before they can sign in — this runs in the background and takes a moment, where the single-database edition is instant.
- Database-creation privileges. The platform's database user must be allowed to create and drop databases.
Which model should you run?
| Single-database (this guide) | Multi-database | |
|---|---|---|
| Data separation | One shared DB, scoped by company_id | A separate DB per tenant |
| Best for | Many smaller tenants, lowest cost | Fewer, larger tenants needing hard isolation |
| Sign-up speed | Instant | A short provisioning wait |
| Ops overhead | One database | One per tenant |
| Isolation | Enforced in software | Physical |
Neither is "better" — they suit different businesses. If you're running many small tenants and want the simplest, cheapest setup, single-database is the natural fit. If you have a smaller number of larger customers who need their data physically apart, multi-database earns its extra overhead.
The multi-database edition
The multi-database product is a separate Krayin extension with its own provisioning, email-OTP registration and per-tenant SMTP. Its full write-up lives on Webkul's blog: User Guide for Krayin CRM Multi-DB SaaS.
Where to go next
- How the single-database edition keeps tenants apart → How It Works
- What every tenant gets, on either model → The Tenant Workspace
- Stand your platform up → Installation