Como arquivos de banco de dados SQLite podem ser corrompidos

O SQLite é uma biblioteca de banco de dados embutida, não um serviço cliente-servidor. Ele opera diretamente sobre arquivos no sistema de arquivos, o que dá leveza, mas transfere para o desenvolvedor a responsabilidade por sincronização, locking e integridade física do arquivo. A corrupção não surge de falhas lógicas no SQL ou erros de schema, mas de interferências no nível de I/O: escritas concorrentes sem coordenação, fechamento acidental de file descriptors compartilhados, backups feitos enquanto WAL está ativo, ou mesmo renomeação de arquivos abertos. Esses cenários são silenciosos: o SQLite não bloqueia a operação, mas o dano aparece depois, em leituras truncadas, páginas corrompidas ou falhas de recuperação automática.

Importante: SQLite não é 'imune' à corrupção porque usa transações ACID, ele é resistente *quando usado conforme projetado*. Mas o projeto pressupõe que ninguém vai ler o arquivo .db diretamente com open()/read(), que ninguém vai chamar close() em um fd já usado por outra thread, e que o sistema de arquivos fará locking como prometido. Quando essas suposições quebram, como em NFS com bugs de POSIX lock ou aplicações que linkam duas cópias da biblioteca, a proteção desaparece.

A versão 3.51.0 (2025-11-04) introduziu defesas específicas contra corrupção causada por close() acidental em ambientes multi-processo com WAL ativado, um problema já documentado desde 2013, mas agora mitigado parcialmente. Já a versão 3.47.0 (2024-10-21) trouxe o sqlite3_rsync, primeira ferramenta oficial para backup consistente de bancos ativos via SSH, antes disso, só havia soluções manuais (VACUUM INTO, backup API) ou riscos reais de cópia inconsistente. Isso fecha uma lacuna prática que afetava diretamente casos como o do KeePass, onde o uso de SQLite poderia ter evitado fragilidades de schema e incompatibilidades entre implementações como descrito na documentação oficial.

Para engenheiros de dados e devs que usam SQLite como camada de persistência local, em aplicativos desktop, CLI tools, ou pipelines de backfill, entender os vetores de corrupção é mais crítico que saber escrever bons índices. Um backfill mal orquestrado pode travar o arquivo durante escrita; um processo de backup que ignora o estado do WAL pode gerar cópias inutilizáveis; e uma integração com LLM que expõe o schema do SQLite via prompt injection [[LINK:/newsletter/ceviu-ti/manipulacao-insegura-de-saida-sql-injection-atraves-de-llm|como já alertado]] amplifica o risco de manipulação direta do arquivo. Corrupção aqui não é erro de aplicação: é falha de infraestrutura de dados, e, diferentemente de bancos distribuídos, não há replay automático nem detecção em tempo real.