Multi-tenant explicado pra quem nunca ouviu falar

Multi-tenant é um termo técnico que aparece toda vez que alguém pergunta sobre segurança no Chateau.ia. Como nem todo dono de restaurante é programador, deixa eu explicar o que isso significa e por que importa.

O que é

Multi-tenant é uma arquitetura onde vários clientes compartilham a mesma infraestrutura, mas seus dados são totalmente isolados. Analogia: imagine um prédio com 50 apartamentos. O prédio é compartilhado (elevador, hidráulica, fachada), mas cada apartamento tem fechadura diferente. O morador do 304 nunca entra no 305, mesmo morando no mesmo prédio. No Chateau.ia, o "prédio" é a plataforma. O "apartamento" é o seu restaurante.

Por que importa

Porque alternativa é cada cliente ter prédio próprio (servidor dedicado). Isso aumenta custo em 10x, sem ganho nenhum de segurança real — desde que o multi-tenant seja feito direito. A questão é exatamente essa: feito direito. Tem multi-tenant mal feito no mercado, onde os apartamentos têm a mesma fechadura.

Como o Chateau.ia faz isso

Três camadas de proteção:

1. Identificador de tenant em cada registro. Toda linha do banco tem

uma coluna que diz "esse dado é do restaurante X". Sem ela, o dado fica órfão.

1. Row Level Security (RLS) no banco. Essa é a parte importante. RLS é

uma regra dentro do Postgres que diz: "Mesmo que o código tente buscar dado de outro tenant, o banco recusa". Não é filtro no código — é regra de banco.

1. Auditoria contínua. A cada mês, varremos as queries pra confirmar

que nenhum endpoint está rodando sem filtro de tenant. Em maio de 2026, fechamos 3 sprints de hardening que cobriram exatamente esse ponto.

Por que RLS no banco é diferente

Sem RLS, você confia no código. Se o programador esquecer um filtro, o sistema vaza dado entre tenants. Com RLS, mesmo que o programador esqueça, o banco recusa. É uma rede de segurança a mais.

E o seu restaurante?

Na prática, isso significa: seu DRE, sua margem, seu cardápio, seus funcionários são vistos só por você. Mesmo que outro restaurante esteja hospedado no mesmo servidor físico, eles não conseguem chegar nos seus dados nem por engano de código, nem por ataque. Quando alguém te oferecer SaaS de gestão de restaurante, vale a pergunta: "vocês usam RLS no banco?". Se a resposta for "a gente filtra no código", desconfia. Filtro de código é parte da solução, não toda.