# ADR-003: Row-Level Multi-Tenancy with tenant_id

| Field | Value |
| --- | --- |
| Status | Accepted |
| Date | 2025-01-01 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |

## Context

Every business module must isolate tenant data. Database-per-tenant is operationally heavy for early phases.

## Decision

Use shared databases per service with mandatory `tenant_id` on every business table. Tenant resolution order: `X-Tenant-ID` → `X-Tenant-Slug` → subdomain → custom domain → user `current_tenant_id`. Cross-tenant queries are forbidden.

## Consequences

### Positive

- Simple ops on a single DB per service
- Consistent middleware and repository filters
- Compatible with subdomain and custom-domain white-label

### Negative

- Requires rigorous tenant filters in every query
- Noise-neighbor risk at very large scale (future mitigation possible)

## Alternatives Considered

1. Database-per-tenant
2. Schema-per-tenant

## Related Documents

- [Multi-Tenant Architecture](../multi-tenant-architecture.md)
- [Security Architecture](../security-architecture.md)
- [Project Principles](../../development/project-principles.md)