Multiple Databases
In the multiple databases variant of the SaaS module, every tenant gets its own dedicated database. Nothing is shared between merchants at the data level — each store's tables live in a database of its own.
What you'll learn
- How a database is created for each tenant
- When this variant is the right choice
- What it means for setup, backups, and upgrades
How it works
- The platform keeps a central database for platform-level records — tenants, subscription plans, invoices, and super admin settings.
- When a merchant registers, a new database is created and provisioned for that tenant, with its own tables and seed data.
- On every request, the platform identifies the tenant from the domain and switches the connection to that tenant's database before serving the storefront or admin panel.
- A tenant's products, categories, orders, and customers never leave their own database.
Advantages
- Strongest isolation — one tenant's data never shares tables with another's.
- Per-tenant backup and restore — a single store can be backed up, restored, exported, or cloned on its own.
- Independent scaling — a large tenant can be moved to its own database server without affecting anyone else.
- Compliance friendly — suits merchants with strict data-residency or data-separation requirements.
- Contained risk — a problem in one tenant's database does not touch the rest of the platform.
Things to keep in mind
- Migrations and module upgrades run per tenant, so maintenance grows with the number of stores.
- Higher infrastructure cost — more databases to host, back up, and monitor.
- Registration takes slightly longer, since a database has to be created and seeded for the new tenant.
- The database user configured for the platform must have permission to create databases.
Best for
Platforms with fewer but larger tenants, or merchants that require strict data isolation, their own backups, or the ability to scale on dedicated infrastructure. For many smaller stores at a lower cost, use Single Database instead.
