SQLite em produção: o que Julia Evans aprendeu ao executá-lo de verdade

Julia Evans publica suas anotações sobre SQLite: nada de espetacular, mas tudo muito útil para quem hesita em executar um aplicativo real nesse pequeno arquivo.

O caso concreto

Julia Evans — cujos zines e artigos educaram uma geração de devs sobre os internals do Linux, HTTP, DNS — publicou em 17 de julho de 2026 em seu blog jvns.ca um artigo intitulado « Learning a few things about running SQLite ». Não é um tutorial introdutório, nem um manifesto religioso: é um diário de campo de uma pessoa que colocou o SQLite em produção em seu próprio serviço e anota o que a surpreendeu. Um prazer.

O que aprendemos

Não vamos estragar o artigo — leiam-no, ele está em inglês mas é curto —, mas alguns pontos retornam regularmente nos debates sobre SQLite em produção e merecem ser lembrados aqui para os curiosos:

1. Modo WAL: indispensável para concorrência

Por padrão, o SQLite usa o modo de journal DELETE, onde escritas bloqueiam leituras. No modo WAL (Write-Ahead Logging), as leituras não bloqueiam mais as escritas e vice-versa:

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL (em vez de FULL) aceita perder no máximo a última transação em caso de corte abrupto de energia, em troca de um ganho massivo de performance. É isso que faz, por exemplo, o Litestream e a maioria dos servidores SQLite modernos.

2. Uma única conexão de escrita, várias de leitura

Ao contrário do PostgreSQL, o SQLite não paraleliza escritas. Um padrão clássico em Rust ou Go: uma única conexão reservada para escrita, um pool de conexões para leituras. É o modelo da crate rusqlite conjugada com deadpool-sqlite com essa separação, ou da lib Go mattn/go-sqlite3 com sql.DB configurado com SetMaxOpenConns(1) para escrita.

3. Backups vivos: Litestream ou LiteFS

Fazer backup de um arquivo SQLite “na cópia” quando uma transação está em andamento é a melhor forma de obter um backup corrompido. Dois ferramentas reinam:

• Litestream (por Ben Johnson, também autor do BoltDB): replica continuamente para S3, Backblaze B2 ou GCS. Streaming do WAL, restore rápido.
• LiteFS (mesmo autor, atualmente na Fly.io): vai além, replicação multi-nós com leitura a partir de qualquer réplica.

4. O verdadeiro limite do SQLite em 2026

O SQLite aguenta sem problemas dezenas de milhares de requisições por segundo em um único arquivo, desde que esteja em WAL e bem indexado. O verdadeiro limite não é SQL, é o disco: NVMe local >> disco de rede, EBS gp3 >> EFS. Muitos fracassos do SQLite em produção vêm de ter colocado o arquivo em um compartilhamento de rede (NFS, notadamente — o SQLite o desaconselha explicitamente em negrito em sua documentação sqlite.org/faq.html#q5).

Para lembrar

O ponto de vista de Julia Evans, como sempre, é: experimentar, medir, escrever o que se encontra. Nada de “SQLite escala” nem “você precisa do Postgres para qualquer coisa real”. Apenas: esse comportamento me surpreendeu, aqui está o porquê, aqui está o que eu mudei.

Para qualquer dev que hesite em usar a pesada artilharia relacional para um app mono-servidor ou um side project, esse tipo de artigo vale cem benchmarks sintéticos.