--- term: 'Hospedagem Multi-Tenant na Nuvem' seoTitle: 'O que é Hospedagem Multi-Tenant na Nuvem? Guia Completo' headline: 'O que é Hospedagem Multi-Tenant na Nuvem?' slug: hospedagem-multi-tenant category: cloud-architecture shortDefinition: 'Hospedagem multi-tenant na nuvem é um modelo em que um conjunto de servidores e software atende muitos clientes, com isolamento lógico entre os tenants.' relatedTerms: - multi-tenant-database-architecture - tenant-isolation - infrastructure-as-a-service - row-level-security contrastsWith: - multi-tenant-database-architecture faq: - question: 'O que é multi-tenancy na computação em nuvem?' answer: 'É a arquitetura em que uma única instância de software — e a infraestrutura debaixo dela — atende vários clientes, chamados de tenants. Os tenants compartilham computação, armazenamento e um só codebase, mas os dados de cada um ficam logicamente isolados e invisíveis para os demais. É o padrão que faz a economia da nuvem fechar: adicionar um cliente é uma mudança de configuração, não hardware novo.' - question: 'Qual a diferença entre hospedagem multi-tenant e single-tenant?' answer: 'Single-tenant dá a cada cliente uma instância e um banco dedicados — controle máximo e isolamento físico, a um preço maior, com cada instância atualizada separadamente. Multi-tenant compartilha uma instância entre todos os clientes — custo menor por tenant, um ciclo de update para todo mundo, e isolamento imposto de forma lógica, não física. A maioria do SaaS roda multi-tenant; clientes regulados ou muito grandes às vezes justificam single-tenant.' - question: 'Uma nuvem multi-tenant é segura?' answer: 'Sim, quando o isolamento é imposto corretamente — um tenant não enxerga os dados do outro. Os riscos residuais são bugs de aplicação que pulam um filtro de tenant e o raio de dano maior de um sistema compartilhado: um incidente pode tocar todos os tenants. Por isso os designs mais fortes empurram o isolamento para a camada de dados — políticas de linha e controle de acesso por objeto — em vez de confiar que cada query vai lembrar do WHERE.' - question: 'O que é o problema do vizinho barulhento (noisy neighbor)?' answer: 'É quando o uso pesado de CPU, memória ou I/O compartilhados por um tenant degrada a performance de todos os outros na mesma infraestrutura. As mitigações incluem quotas e rate limiting por tenant, agendamento de recursos, autoscaling e — quando um tenant roda quente de forma consistente — particionar o componente disputado, geralmente o banco, em um silo próprio.' - question: 'Como os dados de cada tenant ficam separados em uma nuvem compartilhada?' answer: 'Na camada de banco há três padrões canônicos: schema compartilhado em que cada linha carrega um identificador de tenant (maior densidade, normalmente com row-level security), um schema por tenant em um banco compartilhado, e um banco por tenant (isolamento mais forte, custo mais alto). Por baixo, a infraestrutura soma suas próprias camadas: máquinas virtuais, namespaces de contêiner e micro-VMs separam as cargas de trabalho dos tenants.' - question: 'Multi-tenancy é o mesmo que virtualização?' answer: 'Não. Virtualização divide uma máquina física em máquinas virtuais isoladas; multi-tenancy compartilha uma instância de aplicação entre muitos clientes. Elas se complementam — a virtualização é um dos mecanismos que os provedores usam para isolar as cargas dos tenants, enquanto multi-tenancy é o padrão arquitetural que decide o que será compartilhado em primeiro lugar.' - question: 'Quando escolher single-tenant?' answer: 'Quando regimes regulatórios rígidos ou contratos exigem isolamento físico ou residência de dados, quando um cliente precisa de customização profunda por instância, ou quando a performance garantida de uma conta valiosa compensa o custo. A resposta cada vez mais comum é a tenancy mista: agrupar a maioria dos tenants em infraestrutura compartilhada e isolar em silo os poucos que são regulados, enormes ou barulhentos.' - question: 'Por que multi-tenancy importa para SaaS?' answer: 'É a arquitetura sobre a qual o software por assinatura foi construído. Um codebase atende todos os clientes, então correções e features chegam a todos os tenants de uma vez; a utilização do hardware se dilui pela base de clientes; e o onboarding de um cliente novo custa quase nada. Sem multi-tenancy, cada assinatura carregaria o preço de servidores dedicados e manutenção por cliente.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'The NIST Definition of Cloud Computing (SP 800-145)' url: 'https://csrc.nist.gov/pubs/sp/800/145/final' - name: 'Multitenancy (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Multitenancy' - name: 'PostgreSQL Row Security Policies' url: 'https://www.postgresql.org/docs/current/ddl-rowsecurity.html' - name: 'Row-Level Security and Multi-Tenancy on MongoDB (Back4app Engineering)' url: 'https://www.back4app.com/multi-tenant-mongodb-row-level-security' cta: title: 'Isolamento de tenants sem o encanamento' text: 'O Back4app impõe o acesso por tenant na camada de dados — ACLs em cada objeto, roles por tenant e permissões em nível de classe — para que o isolamento não dependa de cada query lembrar de um filtro. Suba um backend multi-tenant no plano grátis.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: multi-tenant-cloud-hosting --- **Hospedagem multi-tenant na nuvem é um modelo em que um conjunto de servidores e software atende muitos clientes, com isolamento lógico entre os tenants.** Pense em um prédio de apartamentos: os moradores compartilham a estrutura, o encanamento e a rede elétrica, mas cada porta tem a sua fechadura. A alternativa — hospedagem single-tenant — é a casa própria: controle total, aluguel mais alto, e boa parte da manutenção fica com você. ## Principais pontos | Pergunta | Resposta | | --- | --- | | O que é | Servidores e software compartilhados, muitos clientes, dados logicamente separados | | Por que existe | Compartilhar infraestrutura é o que torna o preço da nuvem possível | | A parte difícil | Isolamento — um tenant jamais pode ver os dados nem sentir a carga do outro | | vs. single-tenant | Mais barato, onboarding mais rápido, um ciclo de update — ao custo da separação física | | Onde o isolamento pertence | À camada de dados — não ao WHERE de cada query | ## Como os dados dos tenants ficam separados Todo sistema multi-tenant responde uma pergunta antes das outras: onde mora o isolamento? Na camada de banco há três padrões canônicos — schema compartilhado, schema por tenant e banco por tenant. O schema compartilhado é o cavalo de batalha, e fica mais seguro quando *o próprio banco* impõe a fronteira: ```sql -- Padrão 1: schema compartilhado — cada linha carrega seu tenant CREATE TABLE invoices ( id bigserial PRIMARY KEY, tenant_id uuid NOT NULL, amount numeric(10,2) NOT NULL ); -- Imponha o isolamento no banco, não em cada query ALTER TABLE invoices ENABLE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation ON invoices USING (tenant_id = current_setting('app.tenant_id')::uuid); ``` Com uma [política de nível de linha](https://www.postgresql.org/docs/current/ddl-rowsecurity.html), a query que esquece o filtro de tenant retorna nada em vez de tudo — o modo de falha vira página vazia em vez de vazamento de dados. Em um Backend as a Service, o mesmo princípio se expressa como controle de acesso por objeto em vez de políticas SQL. Cada registro carrega uma ACL nomeando o role do tenant que pode vê-lo, e a plataforma a impõe em cada requisição: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK const doc = new Parse.Object('Invoice'); doc.set('amount', 480); const acl = new Parse.ACL(); acl.setPublicReadAccess(false); // invisible to every other tenant acl.setRoleReadAccess('tenant-acme', true); acl.setRoleWriteAccess('tenant-acme', true); doc.setACL(acl); await doc.save(); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK final doc = ParseObject('Invoice')..set('amount', 480); final acl = ParseACL(); acl.setPublicReadAccess(allowed: false); acl.setRoleReadAccess('tenant-acme', true); acl.setRoleWriteAccess('tenant-acme', true); doc.setACL(acl); await doc.save(); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK var doc = Invoice() doc.amount = 480 var acl = ParseACL() acl.publicRead = false acl.setReadAccess(roleName: "tenant-acme", value: true) acl.setWriteAccess(roleName: "tenant-acme", value: true) doc.ACL = acl doc.save { _ in } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK val doc = ParseObject("Invoice").apply { put("amount", 480) } val acl = ParseACL().apply { publicReadAccess = false setRoleReadAccess("tenant-acme", true) setRoleWriteAccess("tenant-acme", true) } doc.acl = acl doc.saveInBackground() ``` ## Isolamento é um espectro, não um interruptor Entre "tudo compartilhado" e "tudo dedicado" ficam os três formatos de implantação entre os quais a maioria dos sistemas reais escolhe: ```mermaid flowchart LR accTitle: Espectro de isolamento de tenants accDescr: Três formatos de implantação, do pool, em que todos os tenants compartilham app e banco, passando pelo bridge, com app compartilhado mas dados isolados, até o silo, um stack dedicado por tenant. A["Pool
todos os tenants compartilham app + banco
(maior densidade, menor custo)"] --> B["Bridge
app compartilhado, dados isolados
(schema ou banco por tenant)"] B --> C["Silo
stack dedicado por tenant
(isolamento mais forte, custo mais alto)"] ``` Plataformas maduras misturam os três: pool para os muitos tenants pequenos, bridge para os médios, e silo para os poucos que são regulados, enormes ou barulhentos. O erro é tratar a escolha como global — ela pode ser feita por plano, e até por componente. ## Hospedagem multi-tenant vs. single-tenant | Dimensão | Multi-tenant | Single-tenant | | --- | --- | --- | | Custo por tenant | Baixo — a infraestrutura é amortizada | Alto — stack dedicado por cliente | | Isolamento de dados | Lógico (políticas, ACLs, schemas) | Físico (instância e banco separados) | | Raio de dano | Um incidente pode tocar muitos tenants | Contido a um cliente | | Vizinhos barulhentos | Possíveis; exigem quotas e throttling | Nenhum — os recursos são privados | | Upgrades | Um rollout atualiza todo mundo | Cada instância atualizada separadamente | | Onboarding | Mudança de configuração, minutos | Provisionamento, de horas a semanas | | Customização | Configuração e feature flags | Mudanças profundas por instância | | Aderência a compliance | Suficiente para a maioria; atrito sob regimes rígidos | Preferido sob mandatos de isolamento estrito | | Uso típico | SaaS, BaaS, plataformas de nuvem compartilhadas | Setores regulados, planos enterprise premium | ## Dois sentidos que vale separar "Hospedagem multi-tenant na nuvem" é usada em duas altitudes diferentes, e a maioria das explicações as embaralha: - **Como camada de hospedagem:** hospedagem compartilhada — sua carga de trabalho roda nas mesmas máquinas físicas que as de outros clientes. É o modo padrão de toda nuvem pública; a [definição do NIST](https://csrc.nist.gov/pubs/sp/800/145/final) lista o pooling de recursos entre tenants como característica essencial da própria computação em nuvem. - **Como arquitetura de aplicação:** o *seu* produto atende os próprios clientes a partir de um backend compartilhado — o jeito como software por assinatura é construído. Aqui você é o senhorio, e o isolamento de tenants vira responsabilidade sua, que é onde entram os padrões acima. Os dois sentidos se compõem: um produto SaaS (multi-tenancy no nível da aplicação) normalmente roda sobre infraestrutura de nuvem compartilhada (multi-tenancy no nível da hospedagem), cada camada isolando os próprios tenants. ## O problema do vizinho barulhento Compartilhar significa disputa: o import em massa de um tenant pode deixar lento o checkout de outro. As mitigações padrão, em ordem de escalada: 1. **Quotas e rate limiting por tenant** — limitar o que qualquer tenant pode consumir por janela. 2. **Agendamento de recursos e autoscaling** — absorver picos antes que virem a latência de outra pessoa. 3. **Separação de cargas de trabalho** — mover jobs pesados (exports, analytics) para filas em segundo plano, fora do caminho da requisição. 4. **Silo parcial** — quando um tenant roda quente de forma consistente, dar ao componente disputado (geralmente o banco) uma partição própria e manter o resto no pool. ## Casos de uso comuns - **Produtos SaaS.** Todo app por assinatura atendendo todos os clientes a partir de um codebase — o caso canônico, e a razão de o padrão existir. - **BaaS e hospedagem de plataforma.** Plataformas rodam milhares de apps em infraestrutura compartilhada e isolada, então cada app custa quase zero para provisionar — o modelo por trás dos planos grátis. - **Aplicações B2B com workspaces por tenant.** Uma implantação, muitas organizações clientes, cada uma com seus usuários, roles e fronteira de dados. - **Plataformas internas.** Uma implantação de analytics ou ferramentas compartilhada entre departamentos, isolada por time. - **Agências rodando muitos apps de clientes.** Plataforma compartilhada por baixo, um backend isolado por cliente em cima. ## Multi-tenant, single-tenant ou misto? Matriz de decisão | Escolha multi-tenant quando… | Escolha single-tenant quando… | Escolha misto quando… | | --- | --- | --- | | Você atende muitos clientes com um produto | Regulação ou contratos exigem isolamento físico | A maioria dos tenants é padrão, alguns são regulados | | O custo por cliente precisa se aproximar de zero | O SLA de um cliente justifica capacidade dedicada | Um tenant é 100× maior que a mediana | | Você quer um ciclo de update para todo mundo | Customização profunda por cliente é o produto | Você precisa de um plano premium "dedicado" | | O onboarding precisa ser self-service e instantâneo | Os clientes se contam nos dedos de uma mão | Um tenant barulhento precisa do próprio banco | O padrão é começar multi-tenant e sair dele tenant a tenant, por mérito — encaixar tenancy depois em um codebase single-tenant é muito mais difícil do que mover um cliente quente para um silo mais tarde. ## Limitações e trade-offs - **O isolamento vale o que vale a sua imposição.** Um filtro de tenant esquecido no código da aplicação é o vazamento cross-tenant clássico. Empurre a fronteira para a camada de dados — políticas de nível de linha, ACLs por objeto — para que a plataforma falhe fechada. - **Raio de dano compartilhado.** Uma queda, um deploy ruim ou uma invasão podem afetar todos os tenants de uma vez. Rollouts em estágios e backups por tenant encolhem o dano, não o compartilhamento. - **Vizinhos barulhentos são estruturais.** Quotas e agendamento administram a disputa; só o silo parcial a remove, a preços de silo parcial. - **Teto de customização.** Os tenants compartilham um codebase, então comportamento por tenant vive em configuração e feature flags — uma restrição que clientes single-tenant não têm. - **Contexto de tenant em todo lugar.** Cada query, chave de cache, job e linha de log precisa conhecer o tenant; a complexidade migra da infraestrutura para a aplicação — exatamente o fardo que o isolamento gerenciado na camada de dados existe para absorver. ## Hospedagem multi-tenant no Back4app O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Ele é multi-tenant nas duas altitudes. Como plataforma, roda milhares de backends de app isolados sobre infraestrutura compartilhada — e é por isso que um backend novo provisiona em minutos no plano grátis. Para os tenants da *sua* aplicação, o isolamento é um recurso da camada de dados, não uma convenção: cada objeto carrega uma ACL, roles agrupam usuários por tenant, e permissões em nível de classe definem regras para o schema inteiro, tudo imposto pelo Back4app em cada requisição. O [mergulho de engenharia em row-level security](https://www.back4app.com/multi-tenant-mongodb-row-level-security) mostra o padrão completo em um banco de documentos — sem depender de disciplina de WHERE.