SQLite é o banco de dados mais implantado do mundo — e quase ninguém fala sobre ele

Os bancos de dados que recebem atenção são aqueles que você opera: clusters PostgreSQL, réplicas MySQL, shards MongoDB, serviços gerenciados em nuvem da AWS e Google. O banco de dados que está em mais lugares do que todos eles juntos roda silenciosamente em segundo plano, não requer administrador, consome menos de 1 MB de espaço em disco para sua biblioteca, e é um único arquivo fonte C que qualquer desenvolvedor pode ler em uma tarde.

SQLite está em todo lugar. É o mecanismo de armazenamento dentro de cada aplicativo iOS e Android que precisa de dados estruturados. Está embutido em todo navegador de desktop — Chrome, Firefox, Safari e Edge usam SQLite para histórico, favoritos e dados em cache. É o banco de dados que alimenta o software de gerenciamento de voo em aeronaves Airbus e Boeing. Está dentro de televisores, carros, roteadores e dispositivos médicos. O projeto SQLite estima mais de um trilhão de implantações em uso ativo — um número tão grande que é difícil de verificar, mas também difícil de contestar dado quantas pilhas de software ele sustenta.

O design que o torna diferente

Todo outro banco de dados SQL que você provavelmente usou é um sistema cliente-servidor: o banco de dados roda como um processo separado, você se conecta a ele através de um socket (local ou rede), envia consultas e recebe resultados. SQLite é sem servidor — todo o mecanismo do banco de dados é uma biblioteca que roda dentro do processo da sua aplicação. Não há servidor para iniciar, nenhum arquivo de configuração para gerenciar, nenhum sistema de permissões de usuário, nenhuma porta de rede para abrir. Você faz link com a biblioteca e tem um banco de dados SQL completo.

O banco de dados em si é um único arquivo no sistema de arquivos. Isso é tanto sua maior força quanto sua limitação chave. Mover um banco de dados SQLite é uma cópia de arquivo. Fazer backup é uma cópia de arquivo. Inspecioná-lo não requer ferramentas especiais — SQLite Browser ou a CLI sqlite3 abrirão qualquer arquivo de banco de dados em qualquer sistema operacional. Quando sua aplicação termina, não há nada para desligar.

A limitação é a concorrência: SQLite usa bloqueio em nível de arquivo, o que significa que apenas um escritor pode modificar o banco de dados por vez. Múltiplos leitores concorrentes estão ok; múltiplos escritores concorrentes são serializados. Para aplicações com alta concorrência de escrita — servidores web de alto tráfego lidando com requisições simultâneas — essa restrição importa. Para a grande maioria das aplicações, incluindo a maioria dos aplicativos móveis, ferramentas de desktop e serviços web de tráfego moderado, não importa.

Por que SQLite é confiável o suficiente para voar

A base de código do SQLite é uma das peças de software mais exaustivamente testadas que existem. O projeto mantém aproximadamente 600 vezes mais código de teste do que código de produção — a biblioteca em si tem cerca de 150.000 linhas de C; o conjunto de testes tem cerca de 90 milhões de linhas, incluindo um fuzzer SQL completo, TH3 (um harness de teste comercial para testes rigorosos contra casos extremos), e testes exaustivos de recuperação de corrupção.

O padrão de confiabilidade é incomum para software open source. D. Richard Hipp, o criador do SQLite, o projetou explicitamente para ser adequado para sistemas críticos de segurança aeronáutica, e a Airbus e outros o certificaram de acordo. O banco de dados fornece garantias ACID — Atomicidade, Consistência, Isolamento, Durabilidade — através de um sistema de log de write-ahead (WAL). Uma falha no meio de uma transação deixa o banco de dados em um estado conhecido e bom; o WAL garante que ou a transação inteira é confirmada ou nenhuma dela é, mesmo em caso de perda inesperada de energia.

O piso de desempenho surpreendente

A arquitetura sem servidor do SQLite significa que ele evita a sobrecarga que bancos de dados cliente-servidor incorrem: sem serialização de dados para enviar através de um socket, sem troca de contexto entre processos cliente e servidor, sem planejamento de consultas através de um limite de rede. Para cargas de trabalho onde as consultas são simples e o banco de dados é de tamanho pequeno a médio, o desempenho do SQLite é frequentemente comparável ao PostgreSQL e às vezes mais rápido.

A equipe do SQLite executou benchmarks em 2022 mostrando que para uma carga de trabalho com muita leitura (35 leituras por cada escrita), SQLite em um SSD NVMe comum processou 48.000 transações por segundo em comparação com 7.000 do PostgreSQL — em grande parte porque a arquitetura intra-processo do SQLite elimina a sobrecarga de comunicação entre processos. Para cargas de trabalho com muita escrita, o quadro é mais matizado; o tratamento concorrente de escrita do PostgreSQL lhe dá vantagens em cenários de alta contenção.

A implicação prática: muitas aplicações que recorrem ao PostgreSQL porque é "de nível de produção" teriam bom desempenho e seriam operacionalmente mais simples com SQLite. O serviço D1 distribuído SQLite da Cloudflare e o libSQL da Turso (um fork do SQLite com suporte a replicação) estão construindo infraestrutura em torno da aposta de que a simplicidade do SQLite foi subvalorizada em aplicações do lado do servidor.

SQLite moderno: não é a versão de 2005

O SQLite evoluiu significativamente. O suporte JSON adicionado em 2015 e estendido até 2022 permite consultar e indexar dados JSON aninhados com semântica SQL completa — competitivo com bancos de dados documentais para muitos casos de uso. A extensão Full-Text Search 5 (FTS5) fornece busca em texto completo classificada por BM25 com consultas de prefixo, sem exigir um índice de busca separado. A extensão R*Tree lida com consultas de intervalo geoespacial. Tabelas virtuais permitem que o SQLite consulte fontes de dados externas (arquivos CSV, APIs remotas) com sintaxe SQL.

A adição mais recente é a extensão de busca de similaridade vetorial — sqlite-vss, construída sobre a biblioteca FAISS do Facebook — que adiciona busca aproximada do vizinho mais próximo ao SQLite. Isso significa que um único arquivo SQLite pode armazenar documentos, seus embeddings vetoriais, e realizar busca de similaridade semântica, tornando-o um banco de dados RAG (geração aumentada por recuperação) embarcado viável para aplicações locais de IA. A combinação de consultas estruturadas, busca em texto completo e busca vetorial em um único banco de dados sem configuração é convincente para aplicações que antes exigiam três sistemas separados.

Quando não usar SQLite

A resposta honesta para "devo usar SQLite?" requer reconhecer suas limitações genuínas. Cargas de trabalho de escrita de alta concorrência — pense em uma aplicação web lidando com milhares de transações simultâneas — precisam da concorrência multi-escritor que o PostgreSQL oferece. Conjuntos de dados substancialmente maiores que a RAM disponível se beneficiam do gerenciamento de pool de buffers e do planejador de consultas do PostgreSQL, que é otimizado para cenários de grandes dados. Aplicações que exigem controle de acesso refinado (segurança em nível de linha, permissões em nível de coluna) precisam de um banco de dados baseado em servidor.

Mas essas são limitações que afetam uma minoria de implantações. O aplicativo web CRUD típico, o aplicativo móvel, a ferramenta de desktop, o sistema embarcado e o script de pipeline de dados são todos bem atendidos pela simplicidade do SQLite. O conselho de que SQLite "não escala" ou "não está pronto para produção" está obsoleto há uma década — ele escala verticalmente para tamanhos muito grandes e tem alimentado aplicações de produção de forma confiável desde o início dos anos 2000. A lacuna entre as capacidades reais do SQLite e sua reputação entre desenvolvedores que não o usaram recentemente é substancial, e vale a pena corrigir.