Why should you care?

DataFlow B2B product serves 500 companies — one MySQL instance with tenant_id filter is cost-effective until giant tenant needs shard.

See it live — copy this example

Run in MySQL Workbench or the mysql CLI.

CREATE TABLE tenants (
  tenant_id CHAR(36) PRIMARY KEY,
  name VARCHAR(120) NOT NULL
);
CREATE TABLE orders (
  order_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  tenant_id CHAR(36) NOT NULL,
  order_ref VARCHAR(32) NOT NULL,
  total_inr DECIMAL(12,2) NOT NULL,
  UNIQUE KEY uq_tenant_ref (tenant_id, order_ref),
  KEY idx_orders_tenant (tenant_id)
);
SELECT order_ref, total_inr FROM orders
WHERE tenant_id = '11111111-1111-1111-1111-111111111111';

What happened?

• Every order scoped by tenant_id.
• Unique (tenant_id, order_ref) lets each tenant reuse DF-001 refs.
• App MUST filter tenant_id from JWT — never trust client alone.

Practice next

1. Create tenants and alter orders with tenant_id.
2. Insert two tenants’ orders.
3. Query with tenant A id — only A rows.
4. Row-level security pattern via views: CREATE VIEW v_orders AS SELECT * FROM orders WHERE tenant_id = CURRENT_TENANT();
5. Plan shard when one tenant exceeds 30% data.

Remember

tenant_id on all tenant-owned rows. Composite unique keys per tenant scope. Middleware injects tenant filter every query.

DataFlow B2B SaaS

JWT tenant claim drives WHERE tenant_id = ? on every API SQL.

Outcome: Tenant A never sees Tenant B orders in pen test.