< blog />

Multi-tenant: como estruturar o banco do seu SaaS

Por Vinicius Ambrozio, fundador da VTA Tecnologia · Publicado em 05 de setembro de 2026

Multi-tenant é a decisão de arquitetura que mais pesa no começo de um SaaS e a mais cara de mudar depois. Ela define como os dados de cada cliente ficam separados dos dados dos outros, e um erro aqui não aparece em teste: aparece quando um cliente vê a fatura de outro.

Este guia é um glossário e um guia prático ao mesmo tempo. Explica o termo, compara as três estratégias de isolamento com uma tabela, diz qual usamos na VTA e por quê, e lista os erros que vemos em produtos que chegam pra gente reconstruir.

O que é multi-tenant?

Tenant, em inglês, é inquilino. Um sistema multi-tenant é um prédio: uma estrutura só, vários inquilinos, cada um com a própria porta e sem acesso ao apartamento do vizinho. No SaaS, o tenant costuma ser a empresa cliente, com vários usuários dentro dela, planos, permissões e dados próprios.

O oposto é single-tenant: uma instalação separada do sistema pra cada cliente, como um sistema sob medida rodando na infraestrutura de uma única empresa. Funciona, mas cada cliente novo é um servidor novo, um deploy novo e uma migração de banco a mais pra manter. Multi-tenant é o que permite que um SaaS atenda mil clientes com o custo de operação de um.

A pergunta prática não é se o seu SaaS vai ser multi-tenant. Vai. A pergunta é onde a separação acontece: no banco inteiro, no schema ou na linha.

Quais são as três formas de isolar os dados?

As três estratégias abaixo existem em qualquer banco relacional; os exemplos são em Postgres porque é o que usamos e o que a maioria dos SaaS novos usa. A AWS e a Microsoft publicam guias longos sobre o assunto; a tabela resume o que importa pra decidir.

Estratégias de isolamento de tenant no banco de dados
Estratégia	Como funciona	Vantagens	Custos e riscos	Quando usar
Banco por cliente	Cada tenant tem o próprio banco de dados, às vezes o próprio servidor.	Isolamento máximo; backup e restauração por cliente; fácil de auditar.	Custo de infra e de operação cresce linearmente; migração de schema roda N vezes; relatório entre clientes é difícil.	Contrato ou regulação exigem; poucos clientes grandes que pagam por isso.
Schema por cliente	Um banco, um schema do Postgres por tenant, tabelas repetidas dentro de cada um.	Isolamento lógico forte; custo de infra compartilhado; restauração por schema.	Milhares de schemas degradam o banco; migração roda N vezes; pool de conexão fica complexo.	Dezenas a poucas centenas de clientes, com necessidade de isolamento visível.
Linha com coluna de tenant e RLS	Todas as linhas na mesma tabela, com tenant_id em cada uma e Row Level Security filtrando no banco.	Mais barato de construir e operar; uma migração só; relatórios globais simples; escala a milhares de clientes.	Um bug de política vaza dados; índices precisam incluir o tenant; cliente grande pode pesar nos outros.	Quase todo SaaS novo, do micro SaaS ao B2B médio.

Existe uma quarta opção que é combinação das outras: começar em linha com RLS e mover clientes grandes pra um banco próprio quando o contrato pedir. É o caminho que recomendamos porque adia o custo até que alguém pague por ele.

Por que linha com RLS é a escolha padrão?

Porque coloca a regra de isolamento no lugar que toda consulta passa: o banco. Com Row Level Security, cada tabela tem uma política que diz "esta sessão só enxerga linhas cujo tenant_id é o da sessão". Se um desenvolvedor esquecer o filtro numa consulta, o banco filtra mesmo assim. É a diferença entre confiar que ninguém vai errar e garantir que o erro não vaza.

Na prática, com Supabase ou Postgres direto, o fluxo é: o usuário autentica, o token carrega o tenant, a aplicação abre a sessão com esse tenant configurado, e as políticas fazem o resto. O guia de RLS do Supabase mostra a sintaxe; o que ele não mostra é o hábito que faz funcionar: escrever a política junto com a tabela, nunca depois, e testar com dois tenants desde o primeiro dia.

É a estratégia que usamos na VTA pra SaaS novos e a que sugerimos quando reconstruímos um produto que nasceu em no-code. Ela também é a mais barata de orçar, o que aparece direto no custo de criar um SaaS.

Quais erros de multi-tenant custam mais caro?

Os cinco que mais vemos em produtos que chegam pra gente consertar:

Filtrar só na aplicação. Cada consulta tem um where tenant_id = ? escrito à mão, e uma delas não tem. Funciona por meses, até que um relatório novo esquece o filtro. RLS resolve por construção.
Tenant_id sem índice. Toda consulta filtra por tenant; se o índice não começa por essa coluna, o banco lê a tabela inteira pra devolver as linhas de um cliente.
Identificador previsível. IDs sequenciais deixam qualquer usuário adivinhar o ID do vizinho. Sem RLS, isso é uma URL de distância de um vazamento. Use UUID e política no banco.
Usuário que pertence a um tenant só. Cedo ou tarde uma pessoa participa de duas empresas clientes. Modele usuário e tenant como entidades separadas, com uma tabela de vínculo e papel, desde o início.
Backup só do banco inteiro. Quando um cliente pede pra restaurar os dados de ontem, ou pra apagar tudo por conta da LGPD, você precisa conseguir fazer isso por tenant sem tocar nos outros.

Como isso conversa com cobrança e permissões?

O tenant é a unidade que paga. Plano, assinatura e limite de uso ficam no tenant, não no usuário; quem cobra é a empresa cliente, e a Stripe ou o Mercado Pago identificam o cliente por esse mesmo ID. Detalhamos o fluxo em cobrança recorrente em SaaS.

Permissão é outra camada: dentro de um tenant, quem pode ver, editar e administrar. Ela também pode viver em RLS, mas o comum é resolver na aplicação com papéis simples (dono, administrador, membro) e deixar o banco garantir só o isolamento entre tenants. Duas camadas, cada uma cuidando de uma coisa.

Se você está desenhando o banco de um SaaS agora, a ordem que funciona é: tabela de tenants, tabela de usuários, tabela de vínculo com papel, tenant_id em toda tabela de negócio, política de RLS em cada uma, índice começando por tenant_id, e um teste automatizado que cria dois tenants e prova que um não vê o outro. É meio dia de trabalho que evita o pior dia do produto. Conheça o que entra na primeira versão na página de desenvolvimento de SaaS.

Perguntas frequentes

O que é multi-tenant em SaaS?

É uma única instalação do sistema atendendo vários clientes (tenants) ao mesmo tempo, com os dados de cada um isolados dos demais. É o que permite que um SaaS atenda mil empresas com o custo de operação de uma. O oposto, single-tenant, instala uma cópia do sistema pra cada cliente.

Banco por cliente ou tabela compartilhada?

Pra quase todo SaaS novo, tabela compartilhada com coluna de tenant e Row Level Security no Postgres: mais barata de construir, operar e migrar, e o banco garante o isolamento. Banco por cliente só quando contrato, regulação ou um cliente muito grande pagarem por isso, e dá pra mover esse cliente depois.

O que é Row Level Security?

Um recurso do Postgres que aplica uma política de acesso linha a linha dentro do próprio banco. Com ela, a sessão de um tenant só enxerga as linhas daquele tenant, mesmo que a consulta da aplicação esqueça o filtro. É a forma mais segura de isolar dados em tabela compartilhada.

Multi-tenant é seguro pra dados sensíveis e LGPD?

Sim, desde que o isolamento esteja no banco (RLS), os IDs não sejam previsíveis e exista forma de exportar e apagar os dados de um tenant sem tocar nos outros. Esses três pontos atendem os pedidos mais comuns da LGPD e são baratos de fazer no começo.

Dá pra migrar de single-tenant pra multi-tenant depois?

Dá, mas custa: cada tabela ganha coluna de tenant, cada consulta precisa ser revisada e os dados dos clientes existentes precisam ser importados com o ID certo. É muito mais barato nascer multi-tenant, mesmo com um cliente só.

Continue lendo

Quer orçamento de quem constrói?

Conta o que você precisa e em até 24h devolvemos valor e prazo fechados.

Pedir orçamento Chamar no WhatsApp