SQLite como base de dados do WordPress: estado de desenvolvimento, limitações e casos de utilização

Entender bem o WordPress e o SQLite

Atualmente, o WordPress não suporta o SQLite como plataforma de base de dados selecionável de forma normal no núcleo. Os requisitos de sistema oficiais continuam a indicar o MySQL ou o MariaDB; o SQLite não faz parte dos requisitos padrão de uma instalação do WordPress. Quem utiliza o WordPress com o SQLite não se limita, portanto, a alterar uma configuração do núcleo, mas sim a complementar o WordPress com uma camada de integração própria.

Esta camada é fornecida pelo plugin Integração com a base de dados SQLite Pronto. Está disponível no diretório de plugins do WordPress.org e está a ser desenvolvido como um plugin da comunidade ou de funcionalidades. O seu objetivo é testar uma implementação do SQLite e recolher feedback para uma possível integração futura no núcleo. A presença no ecossistema do WordPress.org não significa, portanto, que seja aprovado como parte integrante de uma instalação normal do WordPress.

A iniciativa tem uma longa história: em setembro de 2022, foi publicamente proposto na equipa principal do WordPress que o SQLite passasse a ser oficialmente suportado a longo prazo. Desde janeiro de 2023 que a implementação está disponível como um plugin independente; a ligação à Performance Lab, existente na altura, descreve uma etapa de desenvolvimento, não o caminho padrão atual para qualquer site WordPress.

Para uma classificação fiável, o que conta é o número da versão. À data da pesquisa, 18 de outubro de 2026, a v3.1.0, de 8 de outubro de 2026, é a versão estável. As informações provenientes do ramo de desenvolvimento não devem ser automaticamente consideradas como características desta versão estável. Por outro lado, seria errado equiparar o plugin ativo a uma autorização geral de utilização em produção para todos os casos de utilização do WordPress apenas por esse motivo.

A resposta à pergunta do leitor é, portanto, apenas parcialmente afirmativa: o SQLite pode ser adequado para instalações bem delimitadas, como, por exemplo, para desenvolvimento, demonstrações ou pequenos sites com um único servidor e alterações de âmbito limitado. Para instalações distribuídas, com grande volume de gravações ou críticas para o negócio, o MySQL ou o MariaDB continuam a ser a base oficialmente suportada e, na maioria dos casos, mais adequada. Os fatores decisivos são a arquitetura, os padrões de gravação e a compatibilidade efetiva da pilha de tecnologias utilizada.

Base de dados de ficheiros, compatibilidade «drop-in» e com SQL

A diferença fundamental reside no modelo de armazenamento. O SQLite é um Base de dados de ficheiros: Os dados estão armazenados localmente num ficheiro de base de dados no sistema de ficheiros. Por outro lado, o MySQL e o MariaDB funcionam como serviços de base de dados autónomos, com os quais o WordPress comunica através de uma ligação ao servidor. O SQLite pode, por isso, proporcionar um ambiente mais leve, mas requer um local de armazenamento local adequado e direitos de acesso aos ficheiros apropriados.

O núcleo do WordPress, os temas e a maioria das extensões utilizam a conhecida interface para o acesso à base de dados wpdb. O plugin substitui a camada de base de dados habitual através do drop-in wp-content/db.php. Este drop-in intercepta as consultas e faz a ponte entre o mundo do WordPress, orientado para o MySQL, e o SQLite. Desta forma, a interface da aplicação permanece a mesma para muitos componentes, apesar de a base de dados subjacente mudar.

A camada de mediação é o ponto crucial por trás da afirmação resumida „O WordPress funciona com o SQLite“. O WordPress não gera automaticamente código SQL específico para o SQLite. A documentação do projeto no ramo de desenvolvimento trunk descreve um analisador MySQL que reproduz a gramática SQL e as funções necessárias para o SQLite. Isto explica a abordagem de desenvolvimento, mas não constitui nem uma promessa de versão estável nem uma garantia de que cada consulta ou extensão individual do MySQL seja compatível sem necessidade de adaptação.

Deves verificar com especial cuidado as extensões que geram SQL diretamente, que requerem funções de base de dados ou que gerem as suas próprias tabelas de forma invulgar. Isto aplica-se igualmente a importadores, ferramentas de relatórios e scripts de manutenção. Um tema ou plugin pode funcionar em condições normais e, mesmo assim, falhar durante uma operação administrativa pouco comum, uma atualização ou uma consulta específica devido a uma particularidade do MySQL que não tenha sido contemplada.

As diferenças ao nível do esquema, dos metadados e das consultas típicas continuam a ser relevantes para a avaliação. A visão geral interna sobre Tabelas da base de dados do WordPress e o seu desempenho ajuda a identificar extensões que fazem uso intensivo da base de dados e tabelas próprias como possíveis pontos de verificação. Integração com o SQLite não substitui nem uma análise dessas consultas, nem a responsabilidade de testar as adaptações feitas fora da interface padrão do WordPress antes da sua implementação.

Quando é que o SQLite é tecnicamente viável

Uma decisão sensata não se baseia num número global de visitantes. O que é determinante é a Concurso de redação: O SQLite permite vários leitores em paralelo, mas, por cada ficheiro de base de dados, só pode ocorrer uma operação de escrita de cada vez. Se as alterações coincidirem no tempo, as restantes operações de escrita terão de aguardar. A documentação do SQLite recomenda a utilização de uma base de dados cliente-servidor no caso de muitos clientes independentes, vários computadores ou muitas operações de escrita simultâneas.

Áreas de aplicação bem definidas incluem o desenvolvimento local, formações, demonstrações e instâncias de teste de curta duração. Nesses casos, não é necessário configurar um serviço MySQL ou MariaDB separado, ao mesmo tempo que permite testar de forma controlada a pilha de plugins e temas. Um pequeno site num único servidor também pode ser adequado, desde que seja predominantemente de consulta e que as alterações editoriais sejam raras e não ocorram de forma concentrada no tempo.

No entanto, um site empresarial simples, um blogue pessoal ou uma página de campanha não são, por si só, adequados. Formulários de contacto, áreas reservadas a membros, integrações de newsletters ou pontos finais programados individualmente podem desencadear operações de gravação adicionais. Por isso, verifica não só as visualizações de páginas, mas também as atualizações de opções, os envios de formulários, as tarefas agendadas e as alterações de dados efetuadas por plugins e interfaces externas.

Para lojas com encomendas, sistemas de reservas e de emissão de bilhetes, comunidades ativas ou aplicações com muitas operações de gravação AJAX e REST, esta limitação é, na maioria das vezes, mais significativa. Nesses casos, vários utilizadores podem, quase em simultâneo, guardar encomendas, alterar disponibilidades ou criar publicações. Vários servidores web atrás de um equilibrador de carga também não se coadunam com a abordagem de ficheiros locais que o SQLite pressupõe para este caso de utilização.

O armazenamento em cache cumpre uma função diferente da do SQLite. O armazenamento em cache de páginas ou objetos pode reduzir os acessos de leitura recorrentes e, consequentemente, as consultas à base de dados; no entanto, não transforma uma aplicação com elevado volume de gravações numa instalação do SQLite com poucos conflitos. Por outro lado, o SQLite não substitui nenhum conceito de cache. Para sites já existentes, manter o MySQL ou o MariaDB em conjunto com um sistema de cache adequado pode, por isso, ser a opção menos arriscada, sem necessidade de mudar de plataforma de base de dados.

Avaliar sistematicamente cenários com o SQLite

O que determina se o SQLite é adequado para o WordPress não é o número de visitantes, mas sim a interação entre operações de gravação, configuração do servidor e extensões. O SQLite consegue processar acessos de leitura em paralelo, mas não consegue executar operações de escrita no mesmo ficheiro de base de dados em paralelo de forma ilimitada. Por isso, um único site com muitas visualizações de páginas não é automaticamente inadequado, enquanto que encomendas ou reservas efetuadas simultaneamente podem ser um problema crítico.

A tabela constitui uma pré-seleção, não uma aprovação. Especialmente no caso de um site de uma pequena empresa, um formulário de CRM, uma área de membros ou um serviço externo de automatização podem transformar uma página com poucas atualizações num caso de carga de escrita elevada. Por outro lado, um blogue com muitos leitores continua a ser um candidato plausível, desde que os comentários, os formulários e as alterações administrativas sejam de volume razoável. O próprio plugin salienta que a adequação depende do tráfego e da carga de escrita.

O Multisite é descrito na documentação do projeto do ramo de desenvolvimento como um cenário configurável; além disso, o repositório contém testes específicos para o efeito. No entanto, isso não implica uma aprovação geral para produção em redes de grande dimensão com muitos editores, sites ou integrações. Por isso, trate uma rede como um caso de compatibilidade específico e verifique os processos de gestão, atualização e conteúdo efetivamente utilizados.

O passo prático obrigatório consiste num teste da pilha específica num ambiente isolado. Isso inclui o tema ativo, todos os plugins em produção, plugins MU personalizados, importadores, formulários, pontos finais REST, bem como ferramentas de cópia de segurança e monitorização. O que é decisivo não é apenas se as páginas carregam: cada extensão com as suas próprias suposições SQL ou alterações frequentes tem de passar pela camada SQLite de forma fiável.

Instalação e configuração segura do percurso

Esta configuração é adequada para uma nova instalação de teste ou para uma instalação do SQLite planeada de forma deliberada, não servindo como solução rápida para um ambiente de produção já existente. Antes da ativação, o PHP tem de ter a extensão pdo_sqlite fornecer suporte a PDO; além disso, o plugin requer o SQLite a partir da versão 3.37.0. O PHP necessita de direitos de escrita para o diretório da base de dados selecionado. A caixa de diálogo de configuração verifica estas condições e deteta também eventuais «drop-ins» de bases de dados existentes que possam entrar em conflito.

A versão mínima do SQLite indicada é um requisito técnico do plugin, mas não constitui uma garantia geral para todos os casos de utilização em produção. Desde a versão 3.0 do plugin que Registo antecipado (Write-Ahead Logging) ativado por predefinição. Por isso, os administradores devem verificar qual é a biblioteca SQLite que o ambiente de execução do PHP utilizado carrega efetivamente e incluir as atualizações dos plugins, do PHP e do SQLite nas suas verificações de manutenção e compatibilidade.

Verifica especialmente wp-content/db.php. Este ficheiro é o «drop-in» central do WordPress para a camada da base de dados; não é possível utilizar duas soluções em simultâneo. Se já existir um «drop-in» nesse local, por exemplo, para outra ligação à base de dados ou para uma solução de cache, é necessário esclarecer, antes da instalação, que componente este fornece e se é possível uma remoção completa.

A versão estável 3.1.0 utiliza, por predefinição, subdiretórios com nomes aleatórios em wp-content/database/. O local de armazenamento identificado é indicado em db-path.php registado e através de DB_PATH fornecidas. As ferramentas de cópia de segurança e migração não devem, por isso, pressupor nomes de ficheiros históricos ou um caminho padrão aleatório. As constantes anteriores DB_DIR e DB_FILE estão marcados como obsoletos na versão 3.1; DB_PATH tem prioridade.

Para uma nova instalação planeada, o projeto recomenda um caminho absoluto fora do diretório Web acessível ao público. O diretório de destino deve ser gravável pelo processo PHP. A seguinte configuração deve ser colocada em wp-config.php e constitui um exemplo de configuração, não um guia para a alteração posterior de um site já em funcionamento.

// Dateikonfiguration wp-config.php:
// Beispielpfad außerhalb des öffentlich erreichbaren Webverzeichnisses.
define( 'DB_PATH', '/private/wordpress/database.sqlite' );

Aviso: Um novo DB_PATH não move nenhum ficheiro de base de dados existente. Em vez disso, seleciona um local de armazenamento diferente. Se o valor for alterado sem preparação prévia, o WordPress poderá, por isso, utilizar uma base de dados diferente ou vazia. Planeie em conjunto o caminho, os direitos de acesso, a cópia de segurança e um teste de recuperação antes da implementação em produção.

A estrutura aleatória de diretórios na versão 3.1 limita-se a reduzir a previsibilidade do caminho padrão. Não substitui nem os direitos do sistema de ficheiros nem um local de armazenamento protegido de forma fiável contra a divulgação pública. A opção mais segura é o caminho recomendado fora da raiz do site; se for escolhido outro local de armazenamento, o acesso do servidor Web ao mesmo deve ser igualmente impedido de forma fiável.

Não há mudança de base de dados por ativação

No caso de um site WordPress já existente com MySQL ou MariaDB, a ativação da integração com a base de dados SQLite não constitui uma migração. O plugin cria uma base de dados SQLite separada, inicialmente vazia. As publicações, os utilizadores, as opções, as referências multimédia e os dados dos plugins da base de dados anterior não são transferidos automaticamente. Se a integração for desativada posteriormente, o WordPress volta a ligar-se à base de dados anterior; as alterações efetuadas no SQLite não são transferidas de volta.

Esta separação é útil para testes, mas essencial para migrações em ambiente de produção. Quem pretender efetivamente transferir conteúdos para outra plataforma de base de dados necessita de um plano de migração próprio e compreensível, que inclua a transferência de dados, a verificação de conjuntos de caracteres e opções, bem como um plano de contingência. A simples ativação do «drop-in» não pode substituir este processo.

A designação bases de dados separadas Isto deve ser entendido ao pé da letra: durante o funcionamento do SQLite, ambas as bases de dados podem conter conteúdos diferentes. Uma publicação de teste no SQLite não aparece de repente no MySQL ou no MariaDB após a desativação. Da mesma forma, uma nova publicação no MySQL permanece invisível enquanto o WordPress utilizar o ficheiro SQLite como fonte de dados ativa.

O repositório wp-sqlite-db Define-se como um projeto independente com um único «drop-in» do SQLite e remete para a integração original do SQLite. Por conseguinte, não deve ser equiparado ao repositório atual do WordPress. Os ficheiros, valores de configuração e instruções deste projeto não devem ser transferidos para a atual integração da base de dados SQLite; a documentação do projeto concretamente utilizado é que prevalece em cada caso.

No caso de sites já existentes, a decisão menos arriscada é, muitas vezes, manter o MySQL ou o MariaDB e analisar os pontos de estrangulamento separadamente. O cache de páginas ou de objetos pode reduzir as consultas à base de dados, mas não substitui a migração de dados nem resolve questões de compatibilidade relacionadas com a integração do SQLite. Para classificar consultas típicas do WordPress e abordagens de armazenamento em cache, esta visão geral sobre Desempenho do WordPress e otimização do cache.

Proteger a base de dados SQLite e efetuar cópias de segurança consistentes

No SQLite, a base de dados do WordPress encontra-se num ficheiro no servidor. Este pode conter, entre outros, conteúdos, contas de utilizador, opções e dados de configuração, pelo que deve ser protegido tal como um servidor de base de dados. Um subdiretório padrão com um nome aleatório, que utiliza a versão 3.1, apenas dificulta a adivinhação de um caminho; não substitui direitos de ficheiro corretamente configurados nem restrições de acesso do servidor web.

O projeto recomenda que, DB_PATH definir como um caminho absoluto fora da raiz do site. O PHP necessita de direitos de escrita nesse local, enquanto o servidor web não pode disponibilizar diretamente o ficheiro da base de dados. Esta separação reduz o risco de uma configuração incorreta dentro do diretório acessível ao público tornar o ficheiro acessível. A implementação, a gestão de direitos e a criação de cópias de segurança devem ter expressamente em conta o local de armazenamento escolhido.

No que diz respeito às cópias de segurança, a partir da versão 3.1, é fundamental não definir fixamente nenhum nome de ficheiro histórico nem nenhum caminho padrão presumido. O plugin pode obter o caminho real através de DB_PATH torná-lo disponível durante a execução; por isso, as ferramentas de cópia de segurança, migração e recuperação têm de o identificar após o carregamento do WordPress. Antes de o disponibilizar, deve realizar a recuperação num ambiente separado e documentar o caminho necessário, a configuração e os passos a seguir.

Desde a versão 3.0 do plugin que a integração utiliza, por predefinição, o modo WAL. Neste caso, para além da base de dados principal, podem existir ficheiros complementares com as extensões -wal e -shm pode ocorrer. Por isso, verifique expressamente se a ferramenta de cópia de segurança utilizada suporta o modo WAL da base de dados SQLite em execução e tem em conta estes componentes. Sem a autorização de uma ferramenta deste tipo, não é possível obter uma cópia de segurança consistente apenas através da simples cópia do ficheiro principal.

A versão mínima indicada pelo plugin, SQLite 3.37.0, define o limite técnico mínimo para a integração. Para o funcionamento, deve também verificar qual a versão do SQLite que o PHP utiliza efetivamente e incluir as correções de segurança e de erros dos pacotes PHP e SQLite utilizados no processo regular de atualização. No entanto, sem uma fonte adequada no conjunto de fontes existente, não é possível deduzir uma recomendação fiável para versões superiores do SQLite ou para determinados backports.

As ferramentas de exportação e cópia de segurança não devem ser utilizadas apenas pelo facto de serem conhecidas das instalações do MySQL ou do MariaDB. Verifica, para a ferramenta em questão, se esta suporta a base de dados SQLite na versão atual DB_PATH e é suportado no modo de registo configurado. Em seguida, efetua uma restauração no ambiente de alojamento previsto e verifica se o caminho da base de dados, os componentes necessários da base de dados e a configuração do WordPress são totalmente integrados.

Identificar conflitos e analisá-los de forma específica

A migração deve ser realizada, numa primeira fase, num ambiente de teste ou de preparação, e não na primeira implementação em produção. Antes da instalação, registe os ficheiros existentes em wp-content/db.php bem como plugins, plugins MU e extensões personalizadas que utilizam diretamente o MySQL. Uma segunda base de dados «drop-in» não pode funcionar em paralelo; por isso, o processo de configuração da integração verifica se existem tais conflitos.

Em seguida, verifica os processos concretos, em vez de te limitares apenas à página inicial: registo e administração, criação de conteúdos, pesquisa, formulários, tarefas agendadas, importação e exportação, bem como cópias de segurança e recuperação. Repita os testes após atualizações de plugins e do WordPress. A camada de integração processa a sintaxe do MySQL para o SQLite, mas o suporte descrito no projeto não substitui a verificação das suas próprias consultas ou de funções menos comuns de uma extensão.

Erros frequentes na configuração incluem a falta de pdo_sqlite respetivamente pdo ou direitos de escrita insuficientes para o diretório da base de dados. Igualmente problemática é a suposição de que a ativação transfere conteúdos de uma instalação existente do MySQL ou do MariaDB: ela cria uma base de dados SQLite separada, não uma migração automática de dados. Além disso, um novo DB_PATH não move nenhum ficheiro existente, mas sim aponta para um local diferente.

Se surgirem tempos de espera sob carga, analise primeiro quais as ações que estão a efetuar gravações em simultâneo: por exemplo, encomendas, processamento de formulários, pedidos REST ou tarefas em segundo plano. O SQLite permite vários leitores, mas serializa as operações de gravação por ficheiro de base de dados; além disso, a existência de vários servidores web aumenta os requisitos da arquitetura da base de dados. Isto não é comparável aos mecanismos de bloqueio do MySQL-InnoDB. Para a análise das causas em bases de dados WordPress convencionais, o artigo sobre acessos simultâneos à base de dados e bloqueios.

Escolher a estratégia de base de dados adequada

O SQLite é uma opção aceitável para o WordPress quando o site funciona num único sistema, é predominantemente de leitura e as alterações simultâneas são limitadas e conhecidas. Para tal, o desenvolvimento local, as demonstrações ou pequenos sites editoriais são mais adequados do que aplicações com um elevado volume de transações. O pré-requisito continua a ser a compatibilidade comprovada do tema, dos plugins, dos importadores e de todos os acessos à base de dados próprios efetivamente utilizados.

No caso de implementações distribuídas, vários servidores Web ou operações de gravação concentradas num determinado período de tempo, mantêm-se MySQL ou MariaDB a estratégia de base de dados mais adequada. Isto aplica-se, em particular, a lojas online com encomendas, sistemas de reservas e de emissão de bilhetes, funcionalidades de comunidade e interfaces automatizadas com muitas solicitações de gravação. O fator determinante não é um número global de visitantes, mas sim se processos independentes precisam de alterar simultaneamente a mesma base de dados. Para o acesso direto e simultâneo à base de dados por parte de vários hosts através de uma rede, o SQLite recomenda, em princípio, um sistema cliente-servidor.

Além disso, no caso de um site já existente, a mudança de plataforma não implica automaticamente um projeto de otimização de desempenho. O cache por objeto ou por página pode reduzir as consultas à base de dados e a carga de trabalho do PHP, sem substituir o MySQL ou o MariaDB. O armazenamento em cache e o SQLite resolvem, assim, tarefas diferentes: o primeiro reduz o processamento recorrente, enquanto o segundo altera o modelo de armazenamento e de funcionamento da base de dados. Os requisitos oficiais do WordPress continuam a indicar o MariaDB ou o MySQL como pré-requisitos normais para a base de dados.

Antes da aprovação, uma avaliação do tipo «avançar/não avançar» deve abranger, no mínimo, os seguintes pontos:

• Arquitetura: O WordPress funciona de forma contínua num único servidor, sem que seja necessário que vários hosts abram o mesmo ficheiro SQLite diretamente através de um sistema de ficheiros em rede?
• Padrões de gravação: As operações paralelas de encomendas, registos, formulários, REST ou AJAX estão limitadas e são testadas num ambiente separado?
• Compatibilidade: O tema, os plugins, os plugins MU e as consultas SQL personalizadas funcionam na instância de teste?
• Drop-ins: O ficheiro wp-content/db.php está isento de conflitos com soluções de base de dados ou de cache?
• Migração: Está claramente documentado que a ativação não transfere conteúdos do MySQL ou do MariaDB?
• Tempo de execução: A biblioteca SQLite carregada pelo PHP cumpre os requisitos mínimos de versão do plugin? E as atualizações do PHP, do SQLite e do plugin estão integradas no processo de manutenção?
• Cópia de segurança: O sistema de cópia de segurança identifica o DB_PATH atual, suporta o modo de registo utilizado e foi realizada e documentada uma restauração num ambiente separado?
• Operações: As atualizações do plugin e do WordPress são garantidas através de um processo de teste repetível?