If you're planning to build a Shopify-style product — a platform where independent businesses sign up, get their own store, and pay you monthly — you will spend a frustrating week reading vendor pages that all claim to be "multi-tenant."
Most of them aren't. They're multi-store, which is a different thing that solves a different problem. This post defines the term in a way you can actually test, explains the database models underneath it, and walks through the platforms that hold up.
Three things people call "multi-tenancy"
Multi-channel / multi-store. One business running several storefronts — different brands, regions, or B2B and B2C — from one admin. Shared ownership, shared team, shared accountability. Nearly every serious platform does this.
Multi-vendor marketplace. One storefront, many sellers, one shared catalog and one checkout. Amazon's model. The customer experiences a single shop.
True multi-tenancy. Unrelated businesses sign up. Each gets an isolated store with its own domain, its own data, its own admin login, its own branding, and its own subscription. A platform operator sits above them all. The tenants have no relationship with each other and, ideally, no awareness of each other.
The third one is what you need if you're building a SaaS commerce product. The first two won't get you there, no matter how many storefronts they support.
A rubric you can test against
Ask these eight questions of any platform. If you get a "no" on more than two, you're going to be building the missing pieces yourself.
- Data isolation — Is one tenant's catalog, order and customer data structurally invisible to every other tenant?
- Own domain — Can each tenant run on its own domain or subdomain, mapped without manual server work?
- Self-service onboarding — Can a tenant sign up and be provisioned without a developer touching anything?
- Scoped tenant admin — Does the tenant admin literally have no way to see that other tenants exist?
- Super-admin layer — Is there a platform-level role that can create, suspend and audit tenants across the whole system?
- Per-tenant branding — Can tenants change theme, layout and content without forking the codebase?
- Single deployment — Does one upgrade propagate to every tenant, or do you upgrade N of them?
- Subscription billing — Is there a way to charge tenants recurring fees, or is that entirely on you?
Criteria 4, 7 and 8 are where most "multi-tenant" platforms quietly fail.
The database models underneath
Before comparing platforms, it's worth understanding the four ways this gets implemented, because the choice is expensive to reverse and it determines almost everything else.
1. Shared database, shared schema (pooled)
Every tenant's rows live in the same tables, separated by a tenant ID column. Every query has to be scoped, usually through a global scope in the ORM.
- Good: cheapest per tenant, one migration for everyone, trivial cross-tenant analytics, fastest tenant provisioning.
-
Bad: isolation is enforced entirely in application code. One unscoped query is a data leak. Per-tenant backup and restore is awkward. "Delete this tenant's data" is a query, not a
DROP DATABASE.
2. Shared database, separate schema
One database, one schema per tenant. Postgres does this natively; MySQL and MariaDB approximate it with one database per tenant.
- Good: a real boundary rather than a convention, still one connection pool.
- Bad: migrations now run N times. Schema drift becomes a genuine operational problem past a few hundred tenants.
3. Database per tenant, shared application
One application deployment; the database connection is swapped per request based on the incoming domain. This is the standard Laravel multi-tenancy pattern.
- Good: clean per-tenant backup, restore and deletion. A GDPR erasure request becomes a well-defined operation. You can put a data-residency story in front of an enterprise buyer.
- Bad: migration fan-out, connection management overhead, cross-tenant reporting needs a separate pipeline.
4. Instance per tenant (siloed)
Separate application, separate database, separate infrastructure per tenant.
- Good: maximum isolation. Noisy neighbours are impossible. Per-tenant scaling and regional deployment.
- Bad: you've given up the economics that made multi-tenancy attractive. N stacks to provision, monitor, patch and upgrade. Arguably this isn't multi-tenancy at all — it's automated single-tenant hosting.
Which one you want
| Pooled (1 & 2) | Isolated (3 & 4) | |
|---|---|---|
| Cost per tenant | Low | High |
| Migration effort | One run | Fans out across tenants |
| Blast radius of a bug | All tenants | One tenant |
| Per-tenant backup/restore | Awkward | Native |
| GDPR erasure | Query | Drop |
| Cross-tenant analytics | Native | Needs a pipeline |
| Provisioning time | Seconds | Minutes |
The rough rule: pooled for a long tail of small tenants where margin per tenant is thin, isolated for a small number of large tenants who will pay for the isolation. Platforms that survive usually end up hybrid — pooled by default, isolated for an enterprise tier.
The five platforms
1. Bagisto
Stack: Laravel + Vue.js · Licence: MIT core, commercial multi-tenant module · Site · GitHub
Bagisto's open-source core is a full-featured commerce framework with channels, locales and currencies. True tenancy comes from the Multi-Tenant SaaS module, which adds the super-admin layer, tenant self-registration, per-tenant domains and dedicated tenant dashboards on top.
What makes it worth a serious look is that it's one of the few platforms in this list that lets the operator choose the database model. It ships both a shared-database model, where tenants are logically separated inside one centralized database, and an isolated-database model, where every tenant gets a dedicated database. You pick the one that fits your business at setup, rather than inheriting whatever the framework author preferred.
There's a supporting add-on ecosystem built specifically for tenant deployments — RMA, PWA, pre-order, booking — which matters because generic extensions usually break under tenancy unless someone has done the scoping work.
The production evidence is unusually concrete for an open-source project in this space. Bagisto's published case studies include Ucraft at 150+ registered stores, Vyaparify at 200+, and Dukasasa at 100+. There's a live SaaS demo and dedicated docs.
Cost of this approach: the tenancy module is commercial, not part of the MIT core. If a zero-licence-cost stack is a hard requirement, this is where Bagisto drops out and Vendure becomes your answer. You're also committing to Laravel and PHP, which is either a benefit or a dealbreaker depending on your team.
2. Spree Commerce
Stack: Ruby on Rails · Licence: AGPL core, Enterprise Edition for tenancy · Site · Multi-tenant guide
Spree ships a Multi-Tenant module in its Enterprise Edition, and it's clearly aimed at a specific shape of problem: reseller networks, dealer ecosystems and franchise operators. Each partner gets a branded storefront on its own web address, while the platform owner keeps catalog, pricing and fulfilment centralised.
That framing is worth noticing. Spree's tenancy is built for known partners you onboard, not anonymous strangers who sign up at 3am with a credit card. If your tenants are 400 franchise locations, that's exactly right and the shared-catalog model is a feature. If you're building open-signup SaaS, the fit is looser.
Rails is a mature, well-understood stack with a deep hiring pool. The AGPL licence on the core is worth reading carefully if you're building a hosted product.
3. Vendure
Stack: TypeScript / Node.js + GraphQL · Licence: MIT · Site · Channels docs · Multi-tenant guide
Vendure's Channels feature is the closest thing to native multi-tenancy in a fully open-source commerce framework. Each channel gets its own products, prices, shipping methods, payment methods, currency, language and tax defaults — all from a single Vendure instance. Crucially, you can create administrator roles scoped to a single channel, so a tenant admin doesn't see anything outside their own environment. Vendure's own guide walks through setting this up from the admin UI without writing code.
For a TypeScript team wanting a GraphQL-native, API-first commerce backend with no licence cost, this is a strong default.
Cost of this approach: channels are a partition, not a wall. Everything lives in one database with application-level scoping, and there's no isolated-database option — so per-tenant backup, restore and data residency are your problem to solve. Self-service tenant signup and subscription billing aren't in the box either; you build the provisioning and billing layer yourself.
4. Medusa
Stack: TypeScript / Node.js · Licence: MIT · Site · Store Module docs · Multi-tenant guide
Medusa is a well-designed modular commerce engine, and it's on this list because a lot of teams do build multi-tenant products on it — but you should go in with clear eyes about what's actually provided.
Medusa's own documentation states plainly that it doesn't natively support multi-tenancy. The Store Module lets you create and manage multiple stores within a single instance, but linking products, customers and orders to a specific store is customization you write yourself. There's an open feature request for first-class support, and the original discussion from years back is still instructive on how the community distinguishes multi-store from true multi-tenancy.
The pattern most implementations land on, documented by Medusa partner Rigby, is instance-per-tenant: each tenant gets its own Medusa instance, admin panel and data space, with a platform-level super-admin above and provisioning logic that creates new instances and databases on demand.
That's model 4 from the section above. Genuine isolation, and the right answer for franchise networks or dealer ecosystems where each partner needs isolated customers and staff. But you're now operating N deployments, and you've built the tenancy layer, the provisioning system and the billing yourself.
5. WordPress Multisite + WooCommerce
Stack: PHP / WordPress · Licence: GPL · WooCommerce · WordPress
Worth including because it genuinely qualifies on the rubric and because a surprising number of small platforms run on it. Multisite gives you separate sites with their own content, users and — with WooCommerce on each — their own stores, from one WordPress network with a network admin above. Self-service signup and per-site theming are both solved problems, and the plugin ecosystem for subscription billing is enormous.
Cost of this approach: it does not age well. Plugin compatibility across a network is a recurring maintenance tax, performance work gets harder as the network grows, and the isolation is nominal rather than architectural. Fine at 20 tenants. Painful at 200. If this is your plan, plan the migration off it at the same time.
Who didn't make the list, and why
These are excellent platforms that get described as multi-tenant and aren't:
- Saleor — multi-channel, GraphQL-native, genuinely good. Channels are sales contexts for one business, not tenant boundaries.
- Sylius — Symfony-based, strong multi-channel support. Same distinction.
- Shopware — sales channels and multi-store, aimed at one merchant running several storefronts.
- Adobe Commerce / Magento — the store view hierarchy is powerful multi-store, and it's one business's hierarchy.
- commercetools — runs on multi-tenant cloud infrastructure. That's their architecture, not a feature you get to use to host your own tenants.
None of these are dismissals. If you want one business with eight storefronts, several of them beat everything in the list above. They're just answering a different question.
The matrix
✅ built in · ⚠️ partial, or needs work · ❌ not provided
| Bagisto | Spree | Vendure | Medusa | WP Multisite | |
|---|---|---|---|---|---|
| Data isolation | ✅ | ✅ | ⚠️ | ✅ | ⚠️ |
| Own domain per tenant | ✅ | ✅ | ⚠️ | ✅ | ✅ |
| Self-service onboarding | ✅ | ⚠️ | ❌ | ❌ | ✅ |
| Scoped tenant admin | ✅ | ✅ | ✅ | ✅ | ✅ |
| Super-admin layer | ✅ | ✅ | ⚠️ | ⚠️ | ✅ |
| Per-tenant branding | ✅ | ✅ | ⚠️ | ✅ | ✅ |
| Single deployment | ✅ | ✅ | ✅ | ❌ | ✅ |
| Subscription billing | ✅ | ⚠️ | ❌ | ❌ | ✅ |
| Tenancy models supported | Shared DB + isolated DB | Shared DB | Shared DB | Instance per tenant | Shared DB |
| Licence for tenancy | Commercial module | Enterprise Edition | MIT (in core) | MIT (build it) | GPL |
The bottom two rows are the ones to argue about. Everything above them is table stakes; those two are where the actual trade-off lives.
How to choose
Start with the tenant profile, not the tech. Hundreds or thousands of small tenants paying modest monthly fees? Pooled, and optimise provisioning cost. Dozens of large tenants with procurement departments and compliance questionnaires? Isolated, and price accordingly.
Then ask what you're willing to build. Every platform here gives you some of the eight criteria. The honest question isn't which platform is best — it's which missing pieces you're prepared to own for the next five years. Provisioning and billing are the two most commonly underestimated.
Then let the stack decide the shortlist. TypeScript team with no licence budget: Vendure. TypeScript team that needs hard isolation and will build the platform layer: Medusa. Rails team with a partner network: Spree. PHP/Laravel team that wants tenancy provided rather than built, and wants the pooled-versus-isolated decision to stay open: Bagisto.
One last thing. Whatever you pick, write down which of the eight criteria you're getting and which you're building. That document is worth more than any comparison post, including this one.
I work at Webkul, the company behind Bagisto. I've tried to make the criteria testable so you can disagree with my scoring rather than my conclusions. If I've got something wrong about Vendure, Medusa, Spree or anything else here, say so in the comments and I'll correct the post.
Top comments (0)