SQLite não é um banco de dados 'de brinquedo' — e cada vez mais aplicações reais comprovam isso

SQLite é o banco de dados mais amplamente implantado da história. Ele roda dentro de todo dispositivo Android, todo iPhone, todo navegador desktop, todo Mac e na maioria dos sistemas Windows. Estima-se que existam mais de um trilhão de bancos SQLite em uso ativo. Durante boa parte de sua trajetória, a regra implícita no desenvolvimento web era: SQLite é ótimo para desenvolvimento e testes, mas você migra para Postgres ou MySQL antes de colocar em produção.

Essa regra está sendo ativamente desafiada — não como uma opinião contrária, mas por desenvolvedores que estão rodando sistemas reais de produção e reportando resultados concretos. A mudança é tanto filosófica quanto técnica.

A objeção tradicional

O argumento clássico contra SQLite em aplicações web de produção gira em torno da concorrência. SQLite é um banco de dados baseado em arquivo: todas as leituras e escritas atingem um único arquivo em disco e, embora suporte múltiplos leitores simultâneos, só permite um escritor por vez. No modo WAL (Write-Ahead Logging), habilitado desde 2010, leitores e o escritor único não se bloqueiam — mas você ainda tem um único escritor. Para aplicações com alta concorrência de escrita, essa é uma limitação dura.

A segunda objeção é operacional: se sua aplicação roda em múltiplos servidores, eles não podem compartilhar um arquivo SQLite. Bancos distribuídos como Postgres via TCP/IP são projetados para isso; SQLite não. Isso tornava SQLite essencialmente inviável para aplicações web com escalonamento horizontal.

Ambas as objeções são reais. Nenhuma é universal.

O que mudou: o ecossistema de replicação

Em 2021, Ben Johnson lançou o Litestream — uma ferramenta Open Source que faz streaming do arquivo WAL do SQLite para armazenamento compatível com S3 em tempo quase real. A proposta: você obtém backup automático fora do site com RPO abaixo de um segundo, sem alterar o código da aplicação ou migrar para um banco cliente-servidor. Litestream não resolve a limitação de escritor único; resolve o problema de recuperação de desastres e backup que tornava o SQLite inseguro para produção. Para muitos casos de uso, essa é a preocupação mais urgente.

A Fly.io foi além com o LiteFS, um sistema de arquivos distribuído que usa FUSE para interceptar escritas do SQLite e replicá-las para nós réplicas. O LiteFS oferece um nó primário que aceita escritas e réplicas de leitura que o seguem — similar à replicação via streaming do Postgres, mas para SQLite. Aplicações que conseguem rotear escritas para o primário e leituras para qualquer réplica se beneficiam de escalonamento horizontal de leitura sem trocar de motor de banco.

O esforço mais ambicioso é o Turso, construído sobre o libSQL — um fork da base de código do SQLite que adiciona protocolo de rede, multilocação e replicação de borda. A proposta do Turso é "SQLite na borda": cada usuário recebe um shard de banco rodando geograficamente próximo a ele, eliminando a latência de um banco central. A empresa levantou 32 milhões de dólares em uma Série A em 2023. O libSQL é Open Source; o serviço gerenciado do Turso é o produto comercial. O serviço D1 da Cloudflare usa uma arquitetura similar, oferecendo armazenamento compatível com SQLite como primitiva serverless.

O argumento de desempenho

Para aplicações onde o banco de dados está na mesma máquina que o servidor da aplicação — o que é verdade para uma grande porcentagem de aplicações auto-hospedadas e de médio porte — o SQLite com modo WAL frequentemente mostra Benchmark mais rápido que Postgres ou MySQL para cargas de trabalho OLTP com muitas leituras. O motivo é a eliminação da latência de rede: uma consulta SQLite local não atravessa uma conexão TCP. O custo de uma viagem de ida e volta a um servidor Postgres, mesmo em localhost, é de algumas centenas de microssegundos. Em altos volumes de consulta, isso se acumula.

O artigo COST de 2015 ("Scalability! But at what COST?") fez um ponto relacionado no contexto de processamento distribuído de grafos: uma única máquina rodando código monothread bem ajustado muitas vezes superava sistemas distribuídos como Hadoop para grafos que cabiam na RAM. A percepção se generaliza: sistemas distribuídos têm sobrecarga, e se seus dados cabem em uma máquina, você pode estar pagando essa sobrecarga sem benefício algum.

O modo WAL do SQLite também é extremamente otimizado para alta concorrência de leitura. Benchmarks do Turso e de desenvolvedores independentes mostram consistentemente o SQLite lidando com dezenas de milhares de leituras por segundo em hardware modesto, bem dentro da faixa da maioria das aplicações web de produção.

Quem está fazendo isso na prática

A 37signals — empresa por trás do Basecamp e do Hey — tem sido a defensora pública mais vocal. O post de blog de DHH em 2023 argumentando que SQLite com Litestream é suficiente para a maioria das aplicações web gerou discussão significativa. A 37signals usa um modelo de "um banco por cliente" para parte de sua infraestrutura, onde a propriedade de um arquivo por banco do SQLite se torna uma vantagem: os dados de cada cliente ficam isolados em seu próprio arquivo, e os backups são trivialmente simples.

Muitos desenvolvedores independentes e equipes pequenas migraram para SQLite por razões semelhantes: modelo operacional mais simples, sem processo de servidor de banco separado para gerenciar, backup trivial (copiar o arquivo) e desempenho que atende às necessidades. A ascensão de plataformas como Railway e Fly.io, que facilitam rodar SQLite persistente junto com uma aplicação web, reduziu ainda mais a barreira operacional.

Onde ainda não faz sentido

A restrição de escritor único é um teto real. Aplicações com throughput sustentado de escrita — pipelines de ingestão de análise, sistemas de negociação de alta frequência, plataformas sociais com milhões de operações de escrita simultâneas — realmente precisam de um banco que possa distribuir escritas entre vários nós. SQLite não consegue fazer isso nativamente, e as ferramentas de replicação construídas ao seu redor não mudam o modelo fundamental de escrita.

Conjuntos de dados muito grandes também apresentam desafios. SQLite suporta bancos de até 281 TB em teoria, mas o desempenho prático em bancos acima de algumas centenas de gigabytes degrada. Os recursos de Vácuo, Autovácuo e Particionamento do Postgres são maduros e bem compreendidos em escala; os mecanismos equivalentes do SQLite são mais simples e menos testados em tamanhos grandes.

A regra prática que emerge da comunidade: se seu QPS de escrita está abaixo de alguns milhares por segundo e seu conjunto de dados cabe confortavelmente em um único disco, SQLite com WAL merece uma avaliação séria. Se você precisa de escritas multi-primárias, replicação síncrona entre datacenters ou segurança em nível de linha com hierarquias complexas de papéis, Postgres ainda é a ferramenta certa.

O que mudou é o enquadramento. SQLite não é um brinquedo. É um motor de banco de dados maduro, extensivamente testado, com mais de duas décadas de uso em produção em contextos muito mais exigentes que a maioria das aplicações web. A pergunta não é se SQLite é sério — é se as restrições específicas da sua aplicação se encaixam no modelo dele. Para um número crescente de sistemas de produção, a resposta é sim.