The x-tenant-id Pattern: Multi-Tenant API Without Multi-Tenant Complexity

<p>If your SaaS charges customers and also plugs into those customers' billing stack, you do not have one billing problem. You have two.</p> <p>You need to bill your own customer

<p>Building a B2B SaaS platform for transport companies, I faced a critical architectural decision: separate database per tenant or shared database with logical isolation?</p>

<p>A customer opens their dashboard and sees another company’s invoices.</p> <p>Nobody needed to break in. An endpoint returned data it should never have returned.</p> <p>That’s

<h2> TL;DR </h2> <ul> <li>A multi-tenant app was resolving the active tenant from the <strong>request</strong> (subdomain/header) instead of the authenticated

<h1> Multi-Tenant Auth with Cognito and PostgreSQL Row-Level Security (Part 2) </h1> <p><em>How a single Postgres session variable — <code>app.current_tenant_id</code> —

<p>A multi-tenant Node.js application often starts with something that looks harmless:<br /> </p> <div class="highlight js-code-highlight"> <pre class="highlight

<p>If you've reached for <code>acts_as_tenant</code> or <code>apartment</code> without really understanding what's happening underneath, this tutorial is the correction. We're

<p>Multi-tenancy has three common implementations: a database per tenant, a<br /> schema per tenant, and a column on every row. For a SaaS that starts small and<br /> must stay