Um banco de dados nasceu num navio de guerra

Em 2000, D. Richard Hipp trabalhava para a General Dynamics num contrato com a Marinha dos Estados Unidos. O projeto? Software para o destróier USS Oscar Austin — um sistema que ajudava marinheiros a identificar e isolar tubulações danificadas no navio. O banco de dados usado era o Informix, e toda vez que o servidor caía, o software de Hipp parava de funcionar. E adivinha quem levava a culpa?

“Por que eu não falo direto com o disco?” — foi a pergunta que criou o SQLite.

Hipp aproveitou uma pausa no financiamento do governo (causada por um impasse político entre o Congresso e a Casa Branca) para construir algo que ninguém pediu: um banco de dados relacional completo que roda dentro do próprio processo da aplicação. Sem servidor, sem configuração, sem DBA.

Vinte e seis anos depois, esse “projeto paralelo” está em literalmente 1 trilhão de cópias ativas no planeta. Mais do que qualquer outro software de banco de dados já criado. E a Biblioteca do Congresso dos Estados Unidos acaba de reafirmar o que muitos já sabiam: o SQLite é um dos poucos formatos digitais que ela recomenda para preservar dados para a eternidade.

O que a Biblioteca do Congresso realmente disse

A Biblioteca do Congresso dos EUA mantém uma lista de “Recommended Storage Formats” — formatos que, na opinião dos preservacionistas, maximizam a chance de sobrevivência e acessibilidade contínua de conteúdo digital. Não é uma certificação formal nem um selo de aprovação burocrático. É algo mais significativo: é o veredito de pessoas cuja única missão é garantir que a informação sobreviva séculos.

Para datasets, apenas quatro formatos estão nessa lista:

Repare no padrão: três formatos de texto puro e um banco de dados binário. O SQLite é o único formato binário na lista. Isso não é acidente — é confiança.

Os 7 critérios de avaliação

A Biblioteca usa sete critérios para selecionar formatos recomendados:

1. Disclosure — especificações completas e ferramentas de validação estão disponíveis publicamente?
2. Adoption — o formato é amplamente usado pelos criadores e consumidores da informação?
3. Transparency — é possível analisar a representação digital com ferramentas básicas?
4. Self-documentation — contém metadados descritivos e técnicos embutidos?
5. External Dependencies — precisa de hardware, SO ou software específico para funcionar?
6. Patent Impact — patentes podem impedir a preservação a longo prazo?
7. Technical Protection Mechanisms — tem criptografia ou DRM que impeça a preservação?

O SQLite passa em todos com folga. O formato do arquivo é documentado publicamente byte a byte. Não tem patentes. Não tem DRM. É domínio público — nem licença MIT, nem Apache, nem GPL. Literalmente domínio público.

E a observação mais reveladora da Biblioteca: “O mais significativo não é a aprovação por um corpo de padrões reconhecido, mas a existência de documentação completa.”

Números que não fazem sentido

Eu já vi muitos projetos open source se gabarem de escala. Mas o SQLite opera num nível que desafia a compreensão:

• 1 trilhão+ de bancos de dados em uso ativo
• 4+ bilhões de smartphones, cada um com centenas de arquivos .db
• Presente em todos os iPhones, Androids, Macs, Windows 10+
• Dentro do Chrome, Firefox, Safari
• Nos sistemas de entretenimento do Airbus A350
• No Mars Rover da NASA (sim, em Marte)
• No Skype, iTunes, Dropbox, TurboTax, QuickBooks
• Em todas as instalações de PHP e Python

O SQLite compete com zlib, libpng e libjpeg pelo título de “software mais distribuído da história”. Alguns analistas argumentam que o SQLite já é o #1 se você contar as múltiplas instâncias por dispositivo (cada app pode embutir a sua própria cópia via linkagem estática).

E o tamanho do binário? Menos de 2 MB. Menor que a maioria dos frameworks JavaScript que você instala com npm install.

590x mais código de teste que código de produção

Essa é a parte que me fascina. O SQLite tem aproximadamente 155.800 linhas de código no core. O código de teste? 92 milhões de linhas distribuídas em quatro harnesses independentes.

Vou repetir: a proporção de teste para código é de 590:1.

Antes de cada release, o SQLite roda um “soak test” com mais de 2,5 bilhões de casos de teste. O TH3 (Test Harness #3), que é proprietário, garante 100% de cobertura de branch e 100% de MC/DC (Modified Condition/Decision Coverage — o mesmo padrão usado em software de aviação).

Comparação de cobertura de teste:

SQLite      → 100% branch coverage, 2.5B test cases
PostgreSQL  → ~85% line coverage (estimado)
MySQL       → ~70% line coverage (estimado)
Seu projeto → "funciona na minha máquina" 😅

O projeto também usa extensivamente fuzz testing com AFL, OSS-Fuzz e dbsqlfuzz. Ao longo dos anos, bilhões de inputs mutantes foram gerados — e os casos “interessantes” (que revelaram comportamentos inesperados) são preservados e re-executados em cada build.

Esse nível de teste explica por que bugs críticos no SQLite são essencialmente inexistentes. Eu desafio você a encontrar um CVE sério nos últimos 10 anos que afete a integridade dos dados. Boa sorte.

A promessa de 2050

Richard Hipp fez uma promessa audaciosa: o SQLite terá suporte até pelo menos 2050. Não é um roadmap vago — é uma declaração formal publicada no site oficial.

Mas o mais importante é a garantia de compatibilidade retroativa do formato de arquivo. Um banco .db criado em 2004 abre sem problemas no SQLite 3.x de 2026. E um banco criado hoje vai abrir em 2050. A API em C também mantém compatibilidade retroativa total.

Pense nisso: enquanto cada framework JavaScript morre e renasce a cada 3 anos, e enquanto o MongoDB já teve 4 formatos de storage engine diferentes, o SQLite mantém o mesmo formato binário há mais de duas décadas.

É exatamente essa estabilidade que fez a Biblioteca do Congresso escolhê-lo. Quando sua missão é preservar informação por séculos, você não pode depender de um formato que muda a cada major version.

O Renascimento do SQLite em 2026

Por muito tempo, a recomendação era simples: “use SQLite para desenvolvimento, PostgreSQL para produção”. Fazia sentido. O SQLite não tinha replicação, não suportava escritas concorrentes e não escalava horizontalmente.

Mas uma constelação de tecnologias convergiu nos últimos dois anos para mudar esse cenário completamente:

LibSQL — o fork que respeita a tradição

O LibSQL é um fork open source do SQLite que adiciona features críticas sem quebrar compatibilidade:

• Replicação nativa entre nós
• BEGIN CONCURRENT para múltiplos escritores
• Modo servidor com acesso HTTP/WebSocket
• Busca vetorial embutida (sim, para embeddings de IA)
• User-defined functions em WASM

Turso — SQLite na edge

O Turso é uma plataforma gerenciada baseada no LibSQL que distribui seus dados em 30+ localizações globais. Réplicas embutidas sincronizam diretamente com sua aplicação. Cada tenant pode ter seu próprio banco. Point-in-time recovery e branching estão incluídos.

Cloudflare D1 — serverless sem dor

O D1 integra SQLite diretamente nos Cloudflare Workers. Seus dados vivem na edge, com replicação automática e latência praticamente zero para funções edge.

Litestream — backup contínuo sem drama

O Litestream faz streaming contínuo das mudanças do SQLite para S3 ou outro storage na nuvem. Recovery point-in-time com um binário de poucos MB.

O que mudou no hardware

Uma coisa que pouca gente percebe: o hardware moderno transformou as limitações do SQLite em não-problemas.

Tipo de disco     | IOPS típico    | Impacto no SQLite
------------------|----------------|-------------------
HDD tradicional   | 100-200        | Escritas lentas, gargalo real
SSD SATA          | 10K-50K        | Muito bom para a maioria dos apps
NVMe              | 500K-1M+       | SQLite voa

Com WAL mode (Write-Ahead Logging) e NVMe, o SQLite alcança 10K-50K escritas por segundo com leituras concorrentes ilimitadas. Para a vasta maioria das aplicações web, isso é mais do que suficiente.

Quando usar (e quando NÃO usar) SQLite em produção

Vou ser direto: o SQLite não substitui o PostgreSQL para tudo. Mas a lista de casos onde ele é a melhor escolha ficou surpreendentemente longa:

SQLite brilha em:

• Aplicações read-heavy — blogs, e-commerce, dashboards, APIs de consulta
• Distribuição geográfica — com Turso/D1, seus dados ficam perto do usuário
• SaaS multi-tenant — um banco por tenant, isolamento perfeito
• Apps offline-first — sincronização quando reconecta
• Side projects e MVPs — zero ops, zero custo de infra
• Aplicações embarcadas — IoT, mobile, desktop

PostgreSQL ainda ganha em:

• Escritas massivas concorrentes de múltiplas fontes
• Transações distribuídas com isolamento SERIALIZABLE
• Row-Level Security e controle de acesso granular
• Extensions complexas como PostGIS, pg_vector (embora LibSQL já tenha vector search)

Uma regra prática

Se sua aplicação tem menos de 10.000 requisições por segundo e o ratio de leitura/escrita é maior que 10:1, o SQLite provavelmente é a escolha certa. E se você está usando um VPS simples (DigitalOcean, Hetzner, Fly.io), eliminar o PostgreSQL da stack simplifica absurdamente seu deploy e reduz custos.

SQLite como formato de aplicação

Uma tendência que poucos estão acompanhando: usar SQLite como formato de arquivo para aplicações desktop e mobile. Em vez de salvar dados em JSON, XML ou formato proprietário, você salva em .db.

As vantagens:

• Queries SQL sobre seus dados nativamente
• Transações ACID — sem corrupção em crash
• Índices para busca rápida em datasets grandes
• Formato aberto — qualquer ferramenta SQL lê seus dados
• Portabilidade — um arquivo, qualquer plataforma

Aplicações como o Fossil (sistema de controle de versão criado pelo próprio Richard Hipp) usam SQLite como formato nativo. O Git poderia ter feito o mesmo — e talvez fosse mais rápido em repositórios gigantes.

O site oficial do SQLite argumenta que usar SQLite como formato de aplicação é superior a usar uma “pilha de arquivos” (como faz o Git) ou formatos binários proprietários. E agora, com a chancela da Biblioteca do Congresso, esse argumento ganhou peso institucional.

O que isso muda pra você, dev

Se você está construindo algo novo em 2026, vale repensar suas suposições sobre banco de dados. Algumas reflexões:

Para projetos pessoais e startups early-stage: comece com SQLite. Sério. O Ben Johnson (criador do Litestream) roda empresas inteiras com SQLite em produção e dorme tranquilo.

Para dados que precisam durar: se você está armazenando dados que podem ser relevantes em 10, 20 ou 50 anos — pesquisa acadêmica, dados governamentais, arquivos históricos — o SQLite agora tem o endosso máximo para preservação digital.

Para quem quer simplificar a stack: eliminar PostgreSQL, Redis e 15 serviços do docker-compose é libertador. Um processo, um arquivo, zero dependências.

# Deploy de uma app com SQLite
scp app myserver:/opt/app
scp data.db myserver:/opt/data.db
ssh myserver "systemctl restart app"
# Pronto. Sem migrations. Sem pg_dump. Sem Redis.

Para quem desenvolve com IA: o LibSQL já tem busca vetorial embutida. Isso significa que você pode fazer RAG (Retrieval-Augmented Generation) direto no SQLite, sem precisar de Pinecone, Weaviate ou Qdrant para projetos menores.

Comparação rápida: SQLite vs alternativas para preservação

Se você está escolhendo um formato para dados de longo prazo, aqui vai um comparativo direto:

O SQLite combina a portabilidade do CSV com o poder do SQL. É essa combinação rara que convenceu os preservacionistas.

O banco de dados que sobrevive a tudo

Tem algo poético em um banco de dados criado para um navio de guerra acabar sendo escolhido para preservar a memória da humanidade. O SQLite não tem VC funding, não tem 500 engenheiros no LinkedIn, não faz keynotes no re:Invent. É mantido por uma equipe minúscula liderada pelo mesmo cara que o criou em 2000.

E mesmo assim, está em mais dispositivos que qualquer banco de dados já criado. Passa em mais testes que qualquer software que eu conheço. Prometeu funcionar até 2050 — e tem credibilidade para cumprir.

A próxima vez que alguém sugerir “vamos usar Mongo” no sprint planning, talvez valha perguntar: “por que não SQLite?” Se é bom o suficiente para a Biblioteca do Congresso preservar por séculos, provavelmente aguenta seu CRUD de cadastro de usuários.