SQLite Está Comendo o Mundo

O Banco de Dados Mais Implantado Que Você Nunca Implantou

O SQLite está instalado em mais de um trilhão de dispositivos. Seu celular tem. Seu navegador tem. Toda instalação do macOS vem com ele. Ele alimenta o banco de dados de SMS no Android, o armazenamento de favoritos no Firefox e os metadados de fotos no seu iPhone. E, no entanto, até recentemente, a maioria dos desenvolvedores backend o tratava como um brinquedo — algo para protótipos, aplicativos móveis e scripts locais, não para executar um serviço web real.

Isso está mudando rapidamente.

O Que o SQLite Realmente É

SQLite não é um servidor de banco de dados. Não possui camada de rede, sistema de autenticação ou daemon para gerenciar. É uma biblioteca C que lê e escreve um único arquivo no disco. Você a vincula ao seu aplicativo e a chama diretamente — sem strings de conexão, números de porta ou arquivos de configuração para gerenciar.

O que ele tem: conformidade total com ACID, uma implementação SQL completa (funções de janela, CTEs, suporte a JSON, busca em texto completo), desempenho de consulta em submilissegundos para cargas de trabalho típicas e um formato de arquivo tão estável que a equipe do SQLite garante compatibilidade retroativa até 2050. O banco de dados inteiro é um único arquivo que você pode copiar, enviar por e-mail ou colocar em controle de versão.

Por 30 anos, essa combinação fez dele o banco de dados dominante para casos de uso embarcados — o tipo onde você precisa de persistência sem infraestrutura. Mas "embarcado" está sendo redefinido.

Por Que o Uso em Produção Não Era Óbvio

A crítica tradicional ao SQLite para cargas de trabalho de servidor se resume a duas limitações reais:

• Concorrência: SQLite usa bloqueio em nível de arquivo. No modo WAL (WAL = Write-Ahead Log), leitores não bloqueiam escritores e vice-versa, mas você ainda tem um escritor por vez. Cargas de trabalho de escrita com alta concorrência vão enfileirar.
• Máquina única: O banco de dados vive em um sistema de arquivos. Sem replicação embutida, sem failover de espera, sem escritas em várias regiões. Se o seu servidor morrer, seu banco de dados também morre.

Essas são restrições reais. Mas para a maioria dos aplicativos web, elas são irrelevantes. O aplicativo CRUD médio tem uma proporção de leitura/escrita que é 90% de leituras. Concorrência de escrita além de algumas dezenas de requisições por segundo é um problema que a maioria dos aplicativos nunca terá. A complexidade do Postgres — pool de conexões, lag de replicação, failover de espera, migrações de esquema entre réplicas — existe para resolver problemas que não existem na escala em que a maioria dos desenvolvedores está realmente operando.

A Onda do SQLite Distribuído

O ecossistema que surgiu em torno do SQLite para uso em servidores abordou diretamente as limitações restantes. Três projetos estão impulsionando a mudança.

Turso e LibSQL

LibSQL é um fork de código aberto do SQLite mantido pela Turso. Ele adiciona os recursos que tornavam o SQLite impraticável para implantações em servidores: replicação no modo WAL sobre HTTP, acesso remoto sobre um protocolo nativo, extensões carregáveis habilitadas por padrão e suporte a réplicas embarcadas — o que significa que seu aplicativo pode manter uma cópia local do SQLite que sincroniza a partir de um primário remoto. Você obtém latência de leitura local com durabilidade remota.

O resultado é algo que parece um banco de dados serverless, mas tem o desempenho de um arquivo local. O serviço hospedado da Turso permite que você crie bancos de dados em segundos e os replique entre regiões sem tocar em um arquivo de configuração. O nível gratuito deles é generoso o suficiente para que aplicativos pequenos nunca paguem um centavo.

Cloudflare D1

Cloudflare D1 executa SQLite dentro do Cloudflare Workers na borda. Quando um Worker em Frankfurt consulta o D1, ele está acessando uma instância SQLite rodando no mesmo data center, não cruzando um oceano para alcançar um cluster Postgres na Virgínia. A latência de consulta que era medida em centenas de milissegundos cai para dígitos únicos.

D1 lida com a replicação de forma transparente. Você escreve em um primário, o Cloudflare replica as leituras para locais de borda. A API é SQL padrão — você pode usar drizzle-orm, kysely ou consultas brutas. É SQLite com uma camada de leitura global que você não precisou construir.

SQLite Embutido do Bun

Bun vem com uma ligação nativa SQLite a partir da v1.1 — sem npm install, sem compilação de módulo nativo, sem dependência better-sqlite3 para gerenciar. Você importa bun:sqlite e abre um banco de dados. É isso. Para desenvolvedores JavaScript construindo serviços leves ou ferramentas de linha de comando, o atrito de adotar o SQLite acabou de cair para zero.

Rails 8 Tornou-o o Padrão

O sinal mais importante de que o SQLite cruzou um limiar: Rails 8, lançado no final de 2024, vem com SQLite como o banco de dados padrão para novos aplicativos. Isso não é uma conveniência de protótipo — DHH e a equipe principal do Rails foram explícitos de que o SQLite é a escolha certa para a maioria dos aplicativos, e investiram em ferramentas para torná-lo pronto para produção: solid_queue para trabalhos em segundo plano no SQLite, solid_cache para cache e integração de backup baseada em Litestream.

Quando o framework que definiu o padrão de aplicativo web moderno usa como padrão um banco de dados baseado em arquivo, a conversa da indústria mudou.

O Argumento "SQLite para Tudo"

O argumento não é sutil: para 80% dos aplicativos web, você não precisa de Postgres. Você não precisa de um pool de conexões. Você não precisa de uma réplica. Você precisa de um banco de dados rápido, confiável e que não exija um administrador de sistemas para operar.

SQLite oferece:

• Configuração zero — nenhum servidor para iniciar, nenhum usuário para criar, nenhuma porta para abrir
• Configuração instantânea — crie um arquivo, comece a escrever SQL
• Backups triviais — copie o arquivo, ou use Litestream para replicação contínua para o S3
• Excelente desempenho de leitura — submilissegundo para consultas indexadas em bancos de dados de até dezenas de gigabytes
• Garantias ACID — o modo WAL oferece leituras concorrentes e segurança contra falhas sem ajustes

A simplicidade operacional se acumula. Quando seu banco de dados é um arquivo, sua implantação é mais simples. Seu ambiente de desenvolvimento corresponde exatamente à produção. A depuração é mais fácil. Você pode abrir o banco de dados no DB Browser for SQLite e olhar os dados diretamente.

Onde Ainda Não se Encaixa

SQLite não substituirá o Postgres em todos os lugares. Cenários de escrita em várias regiões — onde você precisa de escritas de baixa latência de múltiplas localizações geográficas simultaneamente — são genuinamente difíceis com SQLite. Você pode contornar isso com réplicas embarcadas do LibSQL e roteamento cuidadoso de escrita, mas não é nativo. Cargas de trabalho de escrita com alta concorrência (pense em um feed social com milhões de escritores simultâneos) vão encontrar o gargalo de escritor único.

O ecossistema do Postgres também é mais profundo: melhores extensões (pgvector, PostGIS, TimescaleDB), ferramentas de observabilidade mais maduras, décadas de conhecimento operacional e controle de concorrência multiversão que lida com contenção de escrita de forma mais elegante. Se você está construindo um sistema onde a taxa de transferência de escrita é o gargalo, o Postgres ainda é a escolha certa.

A Mudança é Real

O padrão aqui não é novo. SQLite passou de "brinquedo" a "opção séria" resolvendo os problemas que o mantinham no mundo embarcado — e fez isso não se tornando mais complexo, mas inspirando um ecossistema que adicionou as peças faltantes ao seu redor. LibSQL adicionou replicação. D1 adicionou a camada de borda. Litestream adicionou backup contínuo. Bun removeu o atrito da instalação.

O resultado é um motor de banco de dados que foi comprovado em produção em um trilhão de dispositivos, não requer infraestrutura para funcionar e agora tem respostas críveis para as duas objeções que costumavam desqualificá-lo. A pergunta não é se o SQLite pode lidar com seu aplicativo — é se seu aplicativo realmente precisa do que o Postgres oferece.

Para a maioria dos aplicativos, a resposta honesta é não.