Você está construindo um produto business to business. Como você isola os dados de um cliente dos de outro?

As três opções são schema compartilhado com uma coluna de tenant id, um schema por tenant e um banco por tenant, trocando simplicidade operacional por isolamento. Schema compartilhado escala melhor e custa menos, mas exige que o filtro de tenant seja aplicado estruturalmente, por exemplo com row level security ou uma camada de dados que sempre o aplique. Banco por tenant dá o isolamento mais forte e a restauração por cliente mais fácil, a um custo operacional real.

Meu padrão é schema compartilhado com um tenant id em toda tabela, porque é o mais barato de rodar e dar onboarding num cliente é um insert em vez de um job de provisionamento. O perigo é óbvio, uma cláusula where faltando vaza dados entre clientes, então eu nunca deixo isso por conta da disciplina. Eu uso row level security com o tenant definido a partir da sessão autenticada, então mesmo uma query escrita à mão não retorna nada fora do tenant, e adiciono testes que deliberadamente tentam ler linhas de outro tenant. Eu migro para schema ou banco por tenant quando existe um motivo real: um cliente com exigência contratual de residência de dados, um punhado de contas enterprise grandes o bastante para serem a própria carga, ou um regime de compliance que quer separação demonstrável. Os custos são os que as pessoas subestimam: uma migração agora roda em cada schema, o pooling de conexões fica mais difícil, e você precisa de automação para provisionamento e restauração por tenant. Eu também já tive que resolver vizinhos barulhentos separadamente, com limites de taxa por tenant, porque isolamento de dados não é isolamento de capacidade.