08.10.2026 · Signal Titans Editorial

Richard Hipp queria um banco de dados sem um servidor que pudesse cair. Hoje o SQLite roda em quase todo lugar.

D. Richard Hipp à esquerda, acima de uma cidade de telhados vermelhos, com um ícone minimalista de um banco de dados que vira um único arquivo.

Em 2000, D. Richard Hipp escrevia um software de controle de avarias para um destróier de mísseis guiados da Marinha dos Estados Unidos, o DDG-79 Oscar Austin, como contratado em um projeto da Bath Iron Works. O aplicativo guardava seus dados em um banco Informix que rodava como um servidor separado. Quando esse servidor ficava indisponível, o software não funcionava. Os usuários viam uma caixa de diálogo dizendo que não era possível conectar, e a culpa caía sobre a equipe do aplicativo.

A reação de Hipp virou uma das perguntas de projeto de maiores consequências do software moderno: por que um programa assim precisa de um servidor de banco de dados?

Um banco de dados que é só uma biblioteca

A maioria dos bancos de dados da época seguia o modelo cliente-servidor. O mecanismo do banco rodava como um processo próprio, muitas vezes em uma máquina própria, e os aplicativos conversavam com ele por meio de uma conexão. Essa arquitetura é excelente para muitos sistemas compartilhados e multiusuário. Mas ela também cria uma dependência. Se o servidor, a rede ou a configuração falham, o aplicativo falha junto.

A alternativa de Hipp foi colocar o mecanismo SQL dentro do próprio aplicativo. Não haveria processo de servidor para instalar, iniciar, administrar ou com o qual perder a conexão. O programa leria e gravaria um arquivo comum no disco, usando uma biblioteca ligada diretamente ao seu próprio código.

Uma interrupção no financiamento do governo deixou Hipp sem contrato por alguns meses, e um colega sugeriu que ele finalmente escrevesse o mecanismo que vivia descrevendo. Segundo Hipp, o primeiro código foi enviado ao repositório em 29 de maio de 2000. A primeira versão pública saiu em agosto de 2000. Essa versão inicial guardava os dados com o GDBM, o gerenciador de banco de dados do GNU. O SQLite 2.0, lançado em 2001, substituiu o GDBM por uma camada de armazenamento em B-tree escrita pelo próprio Hipp e adicionou transações.

Por que o domínio público fez diferença

Como a versão 1.0 dependia do GDBM, na prática ela ficava sob a GPL. Quando Hipp escreveu o novo mecanismo de armazenamento, escolheu não usar nenhuma licença de código aberto. O código e a documentação do SQLite foram dedicados ao domínio público.

Essa decisão reduziu as barreiras para as empresas de um jeito raro. Um fabricante podia colocar o SQLite em um celular, um navegador ou um sistema de carro sem negociar licença nem acompanhar cláusulas de atribuição. Para organizações cujos advogados querem um documento formal mesmo assim, a empresa de Hipp, a Hwaci, vende uma "Warranty of Title", uma garantia jurídica de que os autores tinham o direito de dedicar o código ao domínio público. O dinheiro financia o desenvolvimento. O código continua livre.

De projeto paralelo aos celulares

O primeiro interesse comercial sério veio da indústria móvel. Hipp lembra que a Motorola ligou por volta de 2001 ou 2002 para usar o SQLite em um sistema operacional de celular, e que ele pediu cerca de 80 mil dólares, um valor que na época parecia tudo para ele. A AOL também queria. Depois, a Symbian comparou vários mecanismos de banco de dados para sua plataforma móvel e escolheu o SQLite.

A Symbian então levantou uma preocupação séria: um projeto mantido por tão poucas pessoas tinha um "bus factor" baixo. A resposta foi o SQLite Consortium. Seguindo o conselho de Mitchell Baker, da Mozilla, ele foi estruturado para que os membros financiem o desenvolvimento enquanto os desenvolvedores mantêm o controle do código. Mozilla, Symbian e Adobe estavam entre os membros fundadores.

Por volta de 2005, Hipp viu um protótipo inicial do Android durante uma sessão de depuração. Mais tarde, disse que soube que a plataforma seria enorme. O Android acabou levando o SQLite para todos os aparelhos em que rodava.

Aprendendo a testar como na aviação

A adoção em massa expôs outro problema: os bugs chegavam a milhões de aparelhos. A virada veio pela Rockwell Collins, que apresentou a Hipp o DO-178B, um padrão usado em software aeronáutico crítico para a segurança. Entre outras coisas, ele exige cobertura de testes MC/DC de 100%, ou seja, mostrar que cada condição de cada decisão afeta o resultado por conta própria.

Hipp passou cerca de um ano, com longas semanas de trabalho, levando os testes do SQLite a esse nível. Ele contou que, depois disso, os relatórios de bugs vindos do Android praticamente pararam.

A cultura de testes continua sendo a característica mais marcante do SQLite. A documentação do próprio projeto diz que, na versão 3.42.0, a biblioteca tinha cerca de 155.800 linhas de C, enquanto os testes e scripts de teste somavam cerca de 590 vezes mais código. As suítes simulam de propósito falta de memória, erros de E/S, travamentos e quedas de energia no meio de uma gravação, e depois verificam se o arquivo do banco de dados foi corrompido.

Até onde uma ideia pequena chegou

O projeto SQLite se descreve, com bastante cautela, como provavelmente o mecanismo de banco de dados mais implantado. Sua documentação lista entre os usuários todos os aparelhos Android e iOS, todos os Macs e todas as instalações de Windows 10/11, além dos principais navegadores. Ela estima que provavelmente existem mais de um trilhão de bancos SQLite em uso. Esse número é uma inferência a partir da quantidade de smartphones, não uma medição, mas mesmo como estimativa aproximada coloca o SQLite entre os componentes de software mais usados do mundo.

O mecanismo não substitui bancos cliente-servidor em todos os casos. Sistemas grandes, multiusuário e com muita concorrência ainda têm bons motivos para usar um servidor dedicado. A própria documentação do SQLite diz isso. A força dele é outra: para a enorme quantidade de aplicativos que precisam de armazenamento estruturado confiável em um único aparelho, o servidor mais robusto acabou sendo nenhum servidor.

A lição de projeto

Hipp não se propôs a construir o banco de dados mais comum do mundo. Ele se propôs a eliminar um modo de falha de um aplicativo a bordo de um navio. A ideia que ficou foi tratar uma dependência como um risco antes de tratá-la como um recurso.

Muitos problemas de software são resolvidos adicionando um componente: um cache, um serviço, uma fila, um servidor. A história do SQLite lembra que às vezes o movimento mais duradouro é perguntar qual componente pode ser retirado, e depois testar o que sobra como se vidas dependessem disso.