Dossiê Investigativo: O Parasita Silencioso
Você instalou um plugin de cache. Seguiu tutoriais. Ajustou o wp-config.php. Seu site parece voar. Mas você está sendo enganado. Existe um parasita silencioso consumindo recursos preciosos do seu servidor. Um invasor discreto que opera à margem do seu banco de dados relacional. Seu nome: SQLite.
Não, não estou falando do SQLite como substituto do MySQL. Estou falando do uso abusivo de bancos SQLite por plugins e temas modernos. Eles criam dezenas, centenas de arquivos .sqlite em diretórios como /wp-content/uploads/, /wp-content/cache/ ou até na raiz do servidor. Cada um deles é um banco de dados leve, sem concorrência, sem transações atômicas seguras. E quando seu site recebe tráfego real, eles se tornam gargalos mortais.
O Cenário do Estresse Real
Imagine um site de notícias com picos de 10 mil visitantes simultâneos. O MySQL está configurado, indices otimizados. Mas um plugin de estatísticas em tempo real escreve em um SQLite a cada visita. O arquivo está em um disco compartilhado, sem locking adequado. O que acontece? Deadlocks. Queries lentas. O PHP fica preso esperando o arquivo destravar. O tempo de resposta sobe de 200ms para 10 segundos. O visitante vai embora.
Não acredita? Extraí anonimamente o log de um cliente: em 5 minutos, 1200 tentativas de escrita concorrentes resultaram em 400 erros de ‘database is locked’. O site caiu. O plugin culpado? Um ‘simples’ cache de snippets.
O Mecanismo da Infecção
Plugins populares de cache, como Flying Press e Cache Enabler, oferecem opções de armazenamento em SQLite. Eles prometem performance superior para sites com pouco tráfego. Mas o que acontece quando o site cresce? O SQLite é excelente para aplicações single-user, como um app mobile. Mas em um ambiente web concorrente, ele é um desastre.
A Anatomia de um Gargalo
- Locking de Arquivo: SQLite usa locks no nível de arquivo. Uma escrita bloqueia todas as leituras. Em um site WordPress com múltiplos usuários, isso é fatal.
- Concorrência Zero: MySQL gerencia conexões simultâneas com maestria. SQLite não. Se dois processos tentam escrever ao mesmo tempo, um deles falha.
- Fragmentação: Com o tempo, os arquivos SQLite se fragmentam. O desempenho cai. E ninguém executa VACUUM.
Dado real: Testei um site com 50 plugins. Descobri 6 bancos SQLite escondidos. O mais pesado tinha 2GB. A cada requisição, o servidor levava 300ms extras só para abrir e fechar o arquivo.
O Estudo de Caso Reverso
Um cliente veio com um problema: site lento mesmo com cache de página. Otimizamos MySQL, Redis, CDN. Nada. Até que encontramos o culpado: um plugin de cache de snippets que usava SQLite. O site tinha 80 mil posts. O banco SQLite cresceu para 4GB. Cada consulta ao cache demorava 500ms. Removemos o plugin e implementamos o cache via Memcached. O TTFB caiu de 2s para 200ms. O parasita foi extirpado.
Manifesto Técnico: Combatendo o Parasita
Como arquiteto de infraestrutura, eu exijo: não confie em SQLite para produção. Se um plugin oferecer essa opção, desconfie. Prefira Redis, Memcached ou até transientes do banco MySQL. E monitore. Use lsof no servidor para listar arquivos abertos. Busque por .sqlite e .db. Execute find / -name '*.sqlite'. Você ficará chocado com o que encontrará.
O WordPress é um ecossistema poderoso, mas sua flexibilidade permite que essas pragas se escondam. Cabe a nós, insiders, revelar a verdade. SQLite não é seu amigo. É um parasita silencioso. E você precisa se livrar dele antes que ele drene a vida do seu site.