MySQL dedicado vs SQLite por tenant: escolhendo o isolamento de database para WordPress

Escolher como isolar os dados de cada tenant é a decisão mais importante na criação de um WordPress multi-tenancy. Isso define o limite máximo de segurança do isolamento, o mínimo de esforço operacional e a facilidade com que você pode mover um tenant depois. O GrabWP Tenancy Pro oferece três opções de database por tenant, e a resposta certa depende do tenant, não de dogmas. Este guia detalha o que cada opção isola, quando usá-las e por que você nunca fica preso à sua primeira escolha.

As três opções e o isolamento que cada uma oferece

O GrabWP Tenancy Pro suporta três formas de armazenar os dados de um tenant, listadas em ordem crescente de força de isolamento.

MySQL compartilhado com prefixos de tabela únicos. Todos os tenants vivem no mesmo database MySQL, separados por um prefixo de tabela exclusivo. As tabelas do tenant A e as tabelas do tenant B ficam lado a lado, diferenciadas apenas pelos seus nomes. Isso é um isolamento parcial: os dados são separados logicamente, mas ficam no mesmo local físico, compartilhando um database, um pool de conexões e um raio de impacto. É a opção de menor custo operacional e o único modo de isolamento no plugin gratuito GrabWP Tenancy (combinado com uploads isolados).

Database MySQL dedicado por tenant. Cada tenant recebe seu próprio database MySQL. Isso é isolamento total de dados com zero risco de interferência entre tenants: uma query em um tenant não consegue acessar as tabelas de outro tenant porque estão em databases separados, geralmente com credenciais diferentes. Você mantém todos os recursos do MySQL, incluindo ferramentas padrão de backup, replicação e monitoramento.

Database SQLite por tenant. Os dados de cada tenant vivem em seu próprio arquivo SQLite. Isso também é isolamento total de dados com risco zero entre tenants, mas sem nenhum database server para provisionar. A biblioteca de integração do SQLite já vem embutida na versão Pro, então não há nenhum plugin extra para instalar, e a opção Isolated SQLite está sempre disponível. Os nomes dos arquivos recebem um hash por tenant para segurança e compatibilidade, e o tratamento de erros do SQLite oculta os erros em HTML detalhados enquanto registra as queries que falharam.

O resumo: tanto o MySQL dedicado quanto o SQLite oferecem isolamento total. O prefixo compartilhado troca o isolamento por um custo operacional bem menor. Na maioria das vezes, a sua verdadeira escolha é entre os dois motores de isolamento total.

Quando usar o SQLite por tenant é a decisão certa

O SQLite é a opção mais simples, sem dúvida. Não há database server para instalar, proteger, otimizar ou manter funcionando. Um tenant é um único arquivo, o que torna o provisionamento quase instantâneo e a portabilidade muito simples: copiar, clonar ou arquivar um tenant é uma operação de arquivo, não um processo complicado de dump e restore. A clonagem de tenant funciona com origens em SQLite, então criar um novo tenant a partir de um já existente continua sendo rápido e totalmente independente.

Escolha o SQLite por tenant quando:

• Os tenants são menores ou têm baixa concorrência. O SQLite se destaca quando as gravações não são fortemente concorrentes. Para sites institucionais, hotsites de clientes, portfólios e tenants com baixo tráfego, ele é mais do que suficiente.
• A portabilidade é importante. Um único arquivo com hash por tenant é fácil de mover entre servers, fazer um snapshot ou entregar para o cliente. Nenhum estado de database do lado do server viaja junto com ele.
• Você quer o mínimo de provisionamento. Sem usuário do MySQL, sem etapa de criação de database, sem credenciais de conexão para gerenciar por tenant. O motor já vem no Pro e está pronto para uso.

O SQLite é o padrão prático para frotas de muitos pequenos tenants, onde a simplicidade operacional e a portabilidade por tenant superam a necessidade de processamento bruto de gravações simultâneas.

Quando o MySQL dedicado é melhor

O MySQL dedicado é a escolha mais robusta para tenants com alto tráfego e muitas gravações. O MySQL foi feito para conexões e gravações simultâneas, então um tenant com muitos comentários, atividade de checkout no WooCommerce, publicações frequentes ou muitos usuários logados ao mesmo tempo precisa do seu próprio database MySQL em vez de um único arquivo.

Escolha o MySQL dedicado por tenant quando:

• O tenant tem um alto volume de gravações ou muito tráfego. Usuários gravando dados simultaneamente é exatamente onde um database server de verdade mostra seu valor. O SQLite enfileira as gravações, o MySQL não.
• Você depende das ferramentas padrão. Backups point-in-time, replicação, read replicas, logs de queries lentas e todo o ecossistema de ferramentas de monitoramento e administração do MySQL funcionam desde o início. Se a sua equipe de operações já usa o MySQL, um database dedicado por tenant se encaixa nos procedimentos que eles já conhecem.
• Você precisa de credenciais e cotas por tenant. Ter databases separados facilita a configuração de acessos e a gestão de cada tenant de forma isolada em nível de server.

Você ainda tem o isolamento total de dados, igual ao SQLite, mas com a capacidade de processamento e a maturidade operacional de um database server completo. O custo é o provisionamento: cada tenant precisa de um database e, normalmente, de credenciais.

Quando o prefixo compartilhado é aceitável

O isolamento por prefixo compartilhado não é errado, é uma troca consciente. Ele oferece o menor custo operacional de todas as opções: um database, uma conexão, sem nenhum provisionamento por tenant além do prefixo. Isso é realmente útil no contexto certo.

O prefixo compartilhado é aceitável quando:

• Os tenants são confiáveis e de baixo risco. Sites internos, ambientes de staging ou tenants de um único proprietário, onde não há uma barreira rigorosa de segurança ou termos legais entre eles.
• Você está otimizando para densidade e simplicidade. Juntar vários tenants pequenos em um único database mantém a infraestrutura enxuta e a configuração mínima.
• Você está usando o plugin gratuito. O plugin base GrabWP Tenancy traz o isolamento por prefixo compartilhado e uploads isolados, o que é um ótimo ponto de partida para validar um modelo multi-tenancy antes de fazer um upgrade.

Seja sincero sobre o que ele é: um isolamento parcial. Os dados são separados logicamente, mas compartilham um database físico, por isso ele não tem o risco zero entre tenants que um database dedicado ou arquivo SQLite oferecem. Se os tenants são clientes independentes com necessidades reais de isolamento, passe para um motor de isolamento total.

Você não fica preso: migração entre databases

O fato mais libertador em toda essa decisão: sua primeira escolha não é definitiva. O GrabWP Tenancy Pro suporta a migração entre databases, permitindo que você faça o restore de um tenant entre diferentes tipos de motores. Você pode mover um tenant entre MySQL compartilhado, MySQL dedicado e SQLite em qualquer direção.

Isso muda completamente o peso da decisão. Comece um novo tenant no SQLite pela simplicidade e, quando o tráfego e o volume de gravações aumentarem, migre para um database MySQL dedicado. Agrupe um conjunto de databases dedicados com pouco movimento de volta para arquivos SQLite para reduzir a carga operacional. Promova um tenant de prefixo compartilhado para isolamento total assim que ele passar da fase de teste para produção. Como a migração é apenas um restore entre motores, você está escolhendo um ponto de partida, não uma sentença para a vida toda.

Combine isso com o backup e a clonagem de tenants, e cada tenant se torna uma unidade portátil que você pode mover, fazer um snapshot e realocar conforme as necessidades mudarem. Para ver o lado dos backups nesse fluxo, confira nossa estratégia de backup de tenant para WordPress multi-tenancy e, para o modelo de isolamento mais amplo sem o Multisite, veja como isolar sites de clientes WordPress sem Multisite.

Um roteiro de decisão

Siga esta pequena lista e pare na primeira opção que se encaixar:

1. Os tenants precisam de isolamento total com risco zero de interferência cruzada? Se não (internos, confiáveis ou de baixo risco), o prefixo compartilhado é aceitável e mais barato. Se sim, continue.
2. O tenant tem alto tráfego ou volume de gravações, ou a sua operação depende das ferramentas do MySQL? Se sim, use um database MySQL dedicado por tenant. Gravações simultâneas e ferramentas padrão são os pontos fortes dele.
3. O tenant é menor, tem baixa concorrência, e a prioridade é a simplicidade e portabilidade? Se sim, use o SQLite por tenant. Sem server para provisionar, um arquivo com hash por tenant, fácil de mover e clonar.
4. Não tem certeza, ou espera que o tenant cresça? Comece no SQLite pela simplicidade e migre para o MySQL dedicado mais tarde. A migração entre databases significa que a escolha é reversível.

Um padrão prático para uma frota mista: SQLite como padrão para a grande maioria dos pequenos tenants, MySQL dedicado para aquele grupo menor de tenants mais pesados, e prefixo compartilhado apenas para sites internos de confiança. Como você pode migrar entre os motores, é possível deixar cada tenant começar de forma simples e ganhar seu lugar em um motor mais robusto quando a demanda justificar.

Comece agora

O plugin gratuito GrabWP Tenancy oferece isolamento por prefixo compartilhado e uploads isolados para você validar o seu ambiente multi-tenancy. Quando você precisar de isolamento total por tenant, motores MySQL dedicado ou SQLite, além de migração entre databases, o GrabWP Tenancy Pro libera todas as três opções de database por $9.99/month. Escolha o motor certo para o tenant e mova os tenants entre os motores sempre que as necessidades deles mudarem.