Multi-tenancy explicado:um banco de dados, 1.000 clientes

Multi-tenancy explicado: multi-tenancy significa que vários clientes compartilham um banco de dados, mas cada cliente só consegue ver os próprios dados. É assim que um fundador solo atende 1.000 organizações com uma única aplicação sem reconstruir nada — e funciona por causa de uma coluna que precisa estar em todas as tabelas desde o primeiro dia: organization_id.

Se você está construindo um SaaS com IA, essa é uma das poucas decisões de arquitetura que não dá para corrigir barato depois. Aqui está o que é multi-tenancy, por que a escolha errada custa meses e as regras exatas para passar à sua IA para ela acertar isso.

Multi-tenancy explicado: a analogia do prédio de apartamentos

Pense no seu SaaS como um prédio. Cada cliente é um inquilino. Você tem duas opções.

Você pode construir uma casa separada para cada cliente. Cada casa precisa da própria fundação, do próprio encanamento, da própria manutenção. Dez clientes, dez casas. Mil clientes, mil casas — e, quando você quiser reformar a cozinha, reforma mil cozinhas.

Ou você constrói um prédio de apartamentos. Uma fundação, um encanamento, uma equipe de manutenção. Cada inquilino tem o próprio apartamento, a própria fechadura, a própria chave. Ninguém entra no apartamento do vizinho, mas você só mantém um prédio.

Multi-tenancy é o prédio de apartamentos. Uma aplicação, um banco de dados, um deploy — atendendo todos os clientes, cada um vendo só os próprios dados. É a arquitetura padrão de quase todo produto SaaS que você usa, e é o que torna possível a economia de um SaaS tocado por uma pessoa só.

As três formas de atender 1.000 clientes

Tecnicamente existem três abordagens. Só uma delas faz sentido para um fundador solo:

A terceira opção é aquela em que o mercado convergiu, e é dela que trata este artigo. Um banco de dados para manter. Uma mudança para rodar quando você melhora algo. Um backup. E você pode escalar de 1 para 10.000 clientes sem mudar o schema.

A coluna que toda tabela precisa ter

A regra de ouro: toda tabela que guarda dados de clientes precisa ter uma coluna organization_id. Não "deveria ter". Não "dá para adicionar depois". Precisa ter, desde o primeiro dia.

Você não precisa escrever código para entender. Conceitualmente, cada linha do seu banco de dados ganha uma etiqueta dizendo a qual cliente pertence. Na tabela de tarefas de um gerenciador de tarefas, "Desenhar a home" leva a etiqueta da Acme; "Revisar os números do 3º trimestre" leva a da TechStart. Toda vez que a aplicação lê dados, ela pede só as linhas com a etiqueta do cliente atual. Toda vez que grava dados, carimba a nova linha com essa etiqueta. A Acme vê as tarefas da Acme. A TechStart vê as da TechStart. A etiqueta é a chave do apartamento.

Parece trabalhoso. Também é a base que faz todo o resto funcionar — incluindo a camada de segurança que aplica essa regra automaticamente no nível do banco de dados, que merece (e tem) um artigo próprio.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

"Mas agora eu só tenho um cliente"

Ouço isso o tempo todo. Este é o filme que passa quando você pula a multi-tenancy:

• Dia 1: Você constrói para um cliente. Tudo funciona. Não precisa de etiqueta — todos os dados são dele mesmo.
• Dia 30: Você fecha um segundo cliente. Agora os dois veem os dados um do outro. Pânico. Colocar a etiqueta em todas as tabelas depois significa umas três semanas de trabalho, produção fora do ar e clientes irritados.
• O filme alternativo: você constrói com organization_id desde o dia 1. No dia 30, o segundo cliente simplesmente funciona. No dia 300, você tem 100 clientes e fez zero mudanças no banco de dados.

Um amigo meu construiu o SaaS dele sem multi-tenancy. Quando chegou ao 10º cliente, passou três meses reconstruindo o banco de dados inteiro. Três meses sem nenhuma funcionalidade nova, com os clientes esperando. Não seja essa pessoa.

É também por isso que eu insisto tanto em desenhar o banco de dados antes de escrever o prompt: as decisões que são baratas no primeiro dia — uma coluna, um hábito — ficam brutalmente caras no dia 300.

As três regras que mantêm tudo rápido e seguro

Regra 1: Etiquete todas as tabelas, sem exceção. No momento em que uma tabela fica sem organization_id, ela é um vazamento de dados esperando para acontecer. Quando você der as instruções à sua IA, faça disso uma regra permanente, não um pedido a cada tarefa — é exatamente o tipo de regra que pertence às suas decisões de arquiteto, porque a IA vai pular isso numa boa se você não insistir.

Regra 2: Indexe a etiqueta. Um índice é a lista telefônica do banco de dados — permite ir direto às linhas de um cliente em vez de ler todas as linhas para checar a etiqueta. A diferença não é acadêmica: com 1 milhão de linhas distribuídas entre 1.000 organizações, uma busca sem índice leva uns 2.000 milissegundos. Com índice, a mesma busca leva uns 5. Peça à sua IA para criar um índice em organization_id em toda tabela que ela criar.

Regra 3: Nunca confie no navegador para dizer quem está pedindo. A identidade do cliente precisa vir da sessão de login no servidor, nunca de algo que o navegador envia. Se um usuário mal-intencionado consegue dizer ao seu app "eu sou a organização X", ele consegue ler os dados da organização X. O servidor sabe quem está logado; essa é a única fonte da verdade.

Três regras. Uma coluna. Essa é a diferença entre uma demo e um produto que você consegue vender para o seu segundo, décimo e milésimo cliente.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Perguntas frequentes

O que significa multi-tenancy, em termos simples?

Vários clientes (tenants, ou inquilinos) compartilham uma aplicação e um banco de dados, mas cada um só vê os próprios dados. Como um prédio de apartamentos: uma estrutura, muitos apartamentos privados, uma chave por inquilino. É a arquitetura padrão dos produtos SaaS.

Preciso de multi-tenancy se só tenho um cliente?

Sim — é exatamente quando ela é barata. Adicionar uma coluna organization_id no primeiro dia não custa nada. Encaixá-la depois que chega o segundo cliente custa semanas; um fundador que eu conheço passou três meses reconstruindo tudo no décimo cliente. Coloque desde a primeira tabela.

A IA consegue configurar a multi-tenancy para mim se eu não sei programar?

Sim, se você passar a regra de forma explícita: "toda tabela que guarda dados de clientes precisa ter uma coluna organization_id, com índice, e toda consulta precisa filtrar por ela". As ferramentas de IA seguem esse padrão com confiabilidade quando instruídas — e pulam de forma imprevisível quando não. Você fornece a regra; a IA fornece a implementação.

Um único banco de dados compartilhado é seguro o bastante para dados de clientes?

Sim, quando bem feito. A etiqueta organization_id mais a segurança no nível do banco de dados (row-level security, que aplica a etiqueta automaticamente em toda consulta) é como praticamente todo SaaS moderno faz o isolamento — a mesma abordagem que atende produtos com milhares de organizações. A opção insegura é a versão feita pela metade: banco compartilhado, sem etiquetas, sem garantia.