Directus

Multi-tenancy is crucial for building SaaS products. Simplified, it can cut infrastructure costs significantly. Three main approaches exist: row-level tenancy, schema-level separation, and database-level isolation. Start simple and scale as needed, with row-level tenancy sufficing for most starting apps. Tools like Flyway or Liquibase for migrations, PostgreSQL for database, and PgBouncer for connection management are recommended.

Stop Overengineering Your Multi-tenant Architecture

The Truth About Multi-tenant Architecture

And for the love of all that is holy, stop creating magical tenant-oblivious API endpoints like <code>/my-foobars/</code> and using the JWT or session ‘tenant’ to determine what data to return.
I know it’s easier like that. I know it seems cleaner. I know it feels redundant to pass a tenant ID to an endpoint when you already have the tenant ID in the JWT/session.
I know. But don’t do it.
This is what that endpoint should look like: <code>/foobars/:tenantId</code>, or alternatively <code>/:tenantId/foobars/</code>. I mean it.
The <code>tenantId</code> in the path tells the API what data you are asking for. The <code>tenantId</code> in the JWT tells the API what data you are allowed to request. It’s a subtle difference, but it matters a lot once you want to:
<ul>
<li>
Allow admins or support staff to ‘impersonate’ a particular user for testing or troubleshooting (eliminating a whole class of risky workarounds)
</li>
<li>
Create ‘superusers’ or ‘super-tenants’ where one user can have access to the data for more than one tenant (your enterprise customers will need this)
</li>
<li>
Cache slow API responses in other services or BFFs for performance
</li>
<li>
Create machine-to-machine connections with cross-tenant data access for observability, business intelligence, analytics, or deep integrations
</li>
<li>
Add a secondary auth mechanism; you may be using sessions or JWTs for your site users, but now your big customers want direct API access through API keys, and it’s a whole lot simpler to change your auth middleware in one place than to change every single place a service does a database lookup
</li>
<li>
Move your authorization handling away from services and into a central API Gateway, allowing the actual services to focus on business logic, making them simpler to run locally, and easier to test.
</li>
</ul>
I know. You still don’t want to do it. You’re sticking with the JWT <code>tenantId</code> and <code>/my-foobars/</code> and <code>/my-foobars/favorites/</code> and <code>/projects/</code> and <code>/users/</code> and <code>/stuff-for-you-and-noone-else/</code>. Your endpoints will just not be RESTful, they will not be idempotent, they will be mixing responsibilities, they will be harder to optimise and they will ultimately stop you building features your customers will need.
It’s so easy. Just add the bleeping <code>tenantId</code> to the URL path. You don’t even have to thank me later. Just do it, right now.

This article ignores a requirement step. Do you need hard or soft tenancy? I understand with the explosion of SaaS offerings the data might be skewed towards “it doesn’t matter” or “soft is good enough” but there’s always the first step. Imagine missing, implementing row-level tenancy, and finding out you have customers who won’t pay for your software without a hard data tenancy break? Worse, data residency requirements…
As it seems common recently, there are a lot of article that seemingly want to reduce a hard problem to simple choices or steps. I thought this would be a decently written dive into the topic as it mentions “Overengineering”. It looks more like some mid-level engineer’s complaint to a staff engineer on what they think the problem space looks like.

Looks like a Captain obviuous article to me :D, wow so simple, add tenant_id, Postgress, middleware…all done. This doesn’t cover 1% of all challanges with multi tenant architecture.