Arquitetura ideal para SaaS multi-tenant

Multi-tenant é uma decisão de arquitetura, não de framework. Errar aqui significa reescrever o SaaS quando o primeiro cliente enterprise pedir isolamento — e isso acontece antes do que se espera.

Três padrões viáveis

Row-level (shared schema)

Todos os tenants dividem tabelas com uma coluna `tenant_id`. Isolamento via RLS no Postgres. Barato em custo, ótimo para SaaS com muitos tenants pequenos. Padrão que aplicamos por default.

Schema por tenant

Um schema Postgres por cliente. Bom quando o SaaS tem poucos tenants grandes que exigem isolamento visível ou customização estrutural.

Database por tenant

Bancos separados. Alto custo operacional, indicado apenas para compliance rígido — saúde, finanças em jurisdição regulada.

O que fica fora dessa decisão

• Autenticação e RBAC — sempre em cima do tenant, não paralelo
• Billing — sempre por tenant, integrado ao Stripe do dia zero
• Observabilidade — logs e métricas com dimensão de tenant
• Migrações — scripts idempotentes e versionados