Add Mutli-Tenant Feature

[BjornTheProgrammer]

Thank you for your amazing framework, It is incredibly useful!

I would like to instantiate multiple Medusa stores for separate tenants, this way I would not need to use multiple different databases for each tenant's store alongside different instances of MedusaJS. It would be much harder to maintain such a setup without Medusa handling it natively, additionally, it would consume much more compute resources.

To do so, we would only really need a store_id or tenant_id on every table. I have a client that would be interested in maintaining this feature in the future as well, otherwise, they will likely maintain a fork of Medusa.

Please let me know if you would be interested in such a feature set, and the requirements that you might have for such a feature!

[sumitbhanushali]

you can have multiple databases in one database server by mapping site name to database name. This way no unnecessary schema level changes need to be done and data will also be protected which can otherwise be exposed by some wrong query or missed permissions

[BjornTheProgrammer]

Thank you for your input @sumitbhanushali! We've already considered this as a solution, but it falls short in a few respects. 1) It still requires separate MedusaJS instances, 2) It requires additional overhead for each database and additional connection logic (even if it is on a single server), and 3) It would still require migrations to occur on every single database.

As for the security concerns, this can be mitigated very well by postgresql's row-level security feature.

Making a high-availability read, and write single db is also much easier than a lot of other methods, for example, shopify was able to do so until 2014. And using that method, if you want to shard data in the future, it can be even more complex.

This is why it would be very beneficial for there to be a scheme change to support multiple tenants.

[mnstry]

We really need this too! Have you initiated the fork already?

[BjornTheProgrammer]

It's being internally maintained right now. And it is quite specific just to their needs. So I don't think a public fork will be coming in the near future. I'll ask about it to make sure.

[techspawn]

We would be interested in using and maintaining it in case you make it public.

[trevster344]

I tried to do this a short while ago. There doesn't appear to be any way with existing features to accomplish this. My workaround so far has been to implement each of my tenants as a sales channel and apply middleware to restrict / apply sales_channel_id filtering on many features. This has been pretty successful thus far.

[jpxgen]

Hi @trevster344
I am glad to know that you could achieve through a workaround solution.

Can you please help sharing, how you are able to get the product categories and collections specific only to that sales channel? Also, are the orders separated based on that sales channel?

[trevster344]

@jpxgen hey no problem. As far as product collections and categories go, I would create module links between either module and the sales channel module. Then apply a middleware on the respective routes that checks this using the remote query module. Most of the core features in medusajs are implemented in workflows. Many of these workflows have hooks. Use the hooks as a place to create the link records when products or orders are created. Orders are really easy because they already have the sales channel id field for tenancy filtering. Use a middleware on the order routes to force this or check for this.

[saranshisatgit]

Thank you for your amazing framework, It is incredibly useful!

I would like to instantiate multiple Medusa stores for separate tenants, this way I would not need to use multiple different databases for each tenant's store alongside different instances of MedusaJS. It would be much harder to maintain such a setup without Medusa handling it natively, additionally, it would consume much more compute resources.

To do so, we would only really need a store_id or tenant_id on every table. I have a client that would be interested in maintaining this feature in the future as well, otherwise, they will likely maintain a fork of Medusa.

Please let me know if you would be interested in such a feature set, and the requirements that you might have for such a feature!

You can create a a store and use module link to link it with partner or your desired namespace and keep using that everywhere the same reference! You might need to develop your API route like say partner which can handle all the required isolation. It’s doable not complex but it’s a choice of design !

Store is associated with location and currency which doesn’t need isolation as such , products are connected with channels which are connected with stores and each public key is associated to store which creates the isolation per store level.

[tom-aniol]

Hey @BjornTheProgrammer, hope this helps a bit in topic

We (Rigby) have had many conversations about multi-tenancy and multi-store setups in Medusa and decided to do a deep dive as eBook: Multi-Tenant Architecture in Medusa, covering the different technical approaches and trade-offs.

You can also read a summary on the official Medusa blog: Building a multi-tenant commerce platform with Medusa, written by our CTO.

[BjornTheProgrammer]

Appreciate the write up!

[trevster344b]

@tom-aniol Thank you! I have played a lot with multi tenancy in my apps with medusajs. It's nice to see the different approaches so well documented.

[jkuzmanovik]

Hey everyone, been going pretty deep into this topic recently. Went through the Rigby approach, spent a lot of time reading through the Medusa internals, and honestly the more I dig the more I see this is way harder than just adding a tenant_id on every table.

Here's what I found:

The data layer part is not that hard actually. Adding a column, fixing unique indexes (for example the customer email constraint is a composite on (email, has_account) and it's global — so two tenants can't even have the same customer email), setting up RLS or a MikroORM filter. That part is fine.

But the problem is — Medusa has a few places where raw Knex queries go straight to the database and skip the ORM completely. The pricing module calculatePrices(), all three inventory level methods (getReservedQuantity, getAvailableQuantity, getStockedQuantity), the RBAC recursive CTE, the base repository hard delete() — these don't go through MikroORM at all. So if you add a tenant filter at the ORM level it just won't work for these. RLS fixes this because it works at the PostgreSQL level so it catches everything, but if you try to do it in the app you'd have to go fix each one by hand.

For subscribers and workflows — I was worried about these at first but after looking into it I think they're actually fine. Events carry the entity ID which is a unique ULID, and everything after that just follows that ID. Like order.placed fires once for one specific order, the subscriber picks it up and processes just that order. It doesn't run for every tenant or anything like that. One event, one run, one email to the right customer. Even when you follow foreign keys (order → customer → address) it's all ULIDs pointing to the correct rows. So no issue there.

Where it actually gets problematic is more specific:

Scheduled jobs — these don't have an event with an ID. Like "find abandoned carts older than 24h and send reminder emails" — that's just scanning the whole table. No tenant context so it goes through every tenant's carts. And then which sender do you even use for the email?

Writing new records from background stuff — if some workflow step creates a fulfillment or notification record, what tenant_id goes on it? Reading by ULID works no problem, but when you write something new there's no way to know which tenant it belongs to.

Provider configs — and this one I think is kind of a big deal but I don't see anyone talking about it. Every provider (SendGrid, Stripe, fulfillment, file storage) is a singleton that gets created once when the app starts from medusa-config.ts. Notifications are resolved by channel — one provider per channel, and it actually throws an error if two providers try to use the same channel. So if tenant A and tenant B both want SendGrid but with different API keys and different sender addresses... you just can't do that. The SendGrid provider calls sendgrid.setApiKey() which sets the key globally on the npm module level. Two configs can't even exist at the same time in one process.

The Rigby RLS approach does a good job with data isolation — because it's at the PostgreSQL level it catches all those raw Knex queries too. The scheduled job and write-side problems are real but not huge. The provider config thing though — that's a whole different problem and RLS can't help there at all.

At this point I honestly think for most cases just running a separate Medusa instance per tenant behind a gateway is the better move. You get everything isolated — data, configs, providers — without having to patch the framework or worry about stuff breaking on upgrades. Yeah managing multiple deployments is more work but it's nothing new, people do it all the time.

Would be cool to hear from the Medusa team if there's any plans for native support. Even small things would help a lot — like making provider resolution aware of tenants, or adding tenant context to scheduled job configs.

[trevster344]

You're right its extremely difficult to get anything that doesn't present more effort than benefit. I settled on re-exporting the core medusa endpoints and middlewares with my own tenancy guards in front of them because middlewares were too spotty in their behavior with the core endpoints. It works but there isn't peace of mind for me. I think if I did it all again I'd re-implement the core models and features with tenancy in mind. The core logic is available so its not hard to copy.

On the note of running one app per tenant, its entirely do able and even with default tuning the resources aren't hogged too badly.