O que é SQLite: o banco de dados invisível que roda em quase tudo

SQLite é um banco de dados relacional embutido: uma biblioteca escrita na linguagem C que implementa um mecanismo de banco de dados SQL completo e guarda tudo dentro de um único arquivo no disco. Diferente de sistemas como MySQL ou PostgreSQL, ele não precisa de um servidor rodando em segundo plano, não exige instalação de um serviço nem um usuário administrador para funcionar. O programa simplesmente lê e escreve direto no arquivo. Essa simplicidade radical transformou o SQLite no banco de dados mais usado do planeta — ele está no seu celular, no seu navegador, provavelmente em vários lugares da máquina em que você lê este texto agora, e você nunca precisou instalar nada.

Vale conhecer essa peça de engenharia com calma, porque ela contradiz quase tudo o que costumamos assumir sobre bancos de dados. Não há porta de rede, não há processo separado, não há login. Há um arquivo. E, ainda assim, ele é robusto o bastante para rodar em aviões, satélites e em mais de um trilhão de dispositivos ativos ao mesmo tempo.

De um sistema militar a onipresente: a origem do SQLite

A história começa por volta do ano 2000, quando o americano D. Richard Hipp trabalhava como contratado da General Dynamics, uma gigante do setor de defesa dos Estados Unidos. Hipp foi encarregado de um sistema de controle de danos embarcado em um contratorpedeiro de mísseis guiados da Marinha americana — um software que ajudava os marinheiros a isolar problemas no navio, fechando válvulas e disjuntores para proteger sistemas críticos.

O problema era prático e irritante. Todos os dados desse cálculo ficavam num banco de dados Informix, um sistema cliente-servidor tradicional. Quando o motor do Informix estava fora do ar, o programa de Hipp abria uma caixa de diálogo dizendo que o banco estava indisponível — e os usuários ligavam reclamando que o software dele estava com defeito. Hipp fez então a pergunta que mudaria tudo: por que preciso de um processo separado só para guardar esses dados? Por que não posso ler direto do disco? Afinal, se a máquina está boa o suficiente para o usuário abrir o aplicativo, ela também deveria conseguir ler os dados.

Na época não existia nenhum mecanismo de banco de dados SQL que fizesse isso — pelo menos nenhum que ele encontrasse. Sem Google e sem GitHub, Hipp foi pesquisar na biblioteca de uma universidade local, admitindo não saber quase nada sobre tecnologia de bancos de dados relacionais. Acabou tendo que inventar a solução sozinho. O SQLite 1.0 nasceu em agosto de 2000, com o objetivo de ser um banco manipulável sem instalar um SGBD e sem exigir administrador. Ele implementa a maior parte da especificação SQL-92, e Hipp baseou boa parte da sintaxe na versão 6.5 do PostgreSQL.

O que ninguém previa é que a coisa "viralizaria". Anos depois, a Motorola ligou querendo o SQLite nos celulares — ainda na era dos aparelhos de tampa. Depois vieram a America Online, a Nokia (via Symbian OS, após uma "competição de bancos de dados" que o SQLite venceu), o Google e o Android. Hoje ele está em praticamente todo smartphone e todo computador do mundo.

Banco embutido versus cliente-servidor: a diferença que muda tudo

Para entender o SQLite, é essencial separá-lo mentalmente dos bancos que a maioria de nós aprendeu primeiro. MySQL, PostgreSQL, SQL Server e Oracle seguem o modelo cliente-servidor: existe um programa servidor rodando o tempo todo, escutando numa porta de rede, e seu aplicativo se conecta a ele para pedir e gravar dados. Se o servidor cai, o aplicativo não fala com o banco — foi exatamente a dor que originou o SQLite.

O SQLite é embutido (a documentação usa o termo em inglês, embedded). A biblioteca vive dentro do próprio aplicativo. Ela é, ao mesmo tempo, o SGBD e o banco de dados. Não há conexão de rede, não há processo intermediário. As diferenças práticas são grandes:

• Sem servidor (serverless): nada para instalar, configurar, iniciar ou manter no ar. O banco é uma dependência do seu programa, não uma infraestrutura à parte.
• Portabilidade total: como tudo cabe num arquivo, você pode colocar um banco SQLite num pendrive e qualquer pessoa consegue copiar e abrir o banco em seus projetos, sem nenhum programa instalado antes.
• Leve e autocontido: a própria biblioteca é minúscula, o que faz do SQLite uma excelente opção para sistemas embarcados.

Um mito comum, aliás, é achar que "como o banco é um arquivo, ele fica o tempo todo batendo no disco". Não é bem assim: como qualquer motor de banco de dados sério, o SQLite faz muito trabalho em memória, com cache. Ajustar o tamanho desse cache foi, inclusive, uma das otimizações que o desenvolvedor indie Peter Levels aplicou para resolver problemas de latência em seu aplicativo — a maioria das consultas passou a ser resolvida na memória, sem ir ao disco.

Um único arquivo: como o SQLite guarda tudo

O coração do SQLite é o arquivo único. Ele lê e escreve diretamente em arquivos que costumam ter extensão .db, .sqlite ou .sqlite3 (a nomenclatura varia conforme a versão e a preferência de quem cria). Esse arquivo contém o esquema, as tabelas, os índices e os dados — o banco inteiro.

Na prática, mexer nele é direto. No terminal, o comando sqlite3 meubanco.db abre (ou cria) o banco e entrega um prompt próprio, onde você digita comandos SQL comuns como CREATE TABLE, INSERT e o onipresente SELECT, além de comandos internos que começam com ponto: .tables lista as tabelas, .schema mostra o SQL usado para criar uma tabela, .shell roda comandos do sistema sem sair do prompt e .exit volta ao terminal. O SQLite oferece 14 formatos diferentes de saída para consultas, incluindo CSV, HTML e Markdown, o que o torna surpreendentemente versátil como ferramenta de linha de comando.

Um banco recém-criado começa com zero byte. Depois de criar uma tabela e inserir alguns registros, ele pula para a casa dos poucos kilobytes — continua sendo economia pura. Essa leveza é filosofia de projeto, não acidente.

Tipagem dinâmica e afinidade de tipos

Aqui mora uma peculiaridade importante. A maioria dos bancos SQL usa tipagem estática e forte: o tipo do valor é definido pela coluna que o guarda. O SQLite faz o contrário — usa tipagem dinâmica, em que o tipo está associado ao próprio valor, e não ao lugar onde ele é armazenado. Cada valor cai numa classe de armazenamento: NULL, INTEGER, REAL, TEXT ou BLOB — e um BLOB armazena basicamente qualquer coisa.

Para não quebrar a compatibilidade com o SQL de outros bancos, o SQLite usa o conceito de afinidade de tipo (type affinity): se você declara uma coluna como VARCHAR(255), ele aceita, converte a declaração para a classe mais próxima e simplesmente ignora o limitador de caracteres entre parênteses, pois não impõe restrição de tamanho ali. Ou seja, instruções SQL que rodam num banco fortemente tipado tendem a funcionar do mesmo jeito no SQLite.

Onde o SQLite roda (a resposta é: quase em todo lugar)

O SQLite é multiplataforma e roda em Linux, Windows, macOS, iOS e Android. Como o Android é construído sobre o kernel Linux e usa SQLite internamente, e o iOS faz o mesmo, é seguro dizer que quase todo celular do mundo carrega vários bancos SQLite ao mesmo tempo. Some a isso os navegadores web, aplicativos de desktop e uma infinidade de dispositivos, e chega-se à marca frequentemente citada de mais de um trilhão de bancos ativos. Não há um segundo colocado que chegue perto.

A lista de onde ele aparece é quase cômica de tão ampla:

• Celulares Android e iOS — armazenando contatos, mensagens, configurações e dados de aplicativos.
• Navegadores — vários guardam dados locais em SQLite.
• Aplicativos de desktop e mobile — de editores de texto a apps de produtividade.
• Sistemas embarcados e IoT — TVs, drones, câmeras, consoles e todo tipo de dispositivo "inteligente".
• Aviônica — a Airbus contatou Hipp querendo usar o SQLite no A350, o que o levou a assumir o compromisso de dar suporte ao projeto até 2050, a "vida útil" da estrutura da aeronave.
• Aplicações web de verdade — ao contrário do preconceito de que serve só para brinquedos, o SQLite roda aplicações grandes, e há desenvolvedores tocando SaaS usados no mundo todo com pilhas simples de PHP, jQuery e SQLite.

Também é o queridinho de projetos rápidos: provas de conceito, protótipos, rotinas de testes automatizados e até desafios de processos seletivos — tudo pela facilidade e leveza. E há um ecossistema crescente construído em cima dele, como o framework PocketBase e o fork libSQL, mantido pela Turso, que adiciona modo servidor via HTTP, replicação nativa e a ideia inusitada de "um banco de dados por usuário".

Domínio público: nem GPL, nem MIT, nada

Um ponto que costuma confundir: o SQLite não é licenciado como GPL. Ele é de domínio público. A distinção é real e vale a precisão.

A primeira versão do SQLite chegou a ser GPL, mas por obrigação: ela dependia do GDBM, um armazenamento chave-valor do GNU sob GPL, que "contamina" tudo que o usa. Como Hipp queria fazer consultas por intervalo (que pedem uma estrutura como árvore B), ele reescreveu essa camada de armazenamento do zero na versão 2, eliminou a dependência do GDBM e, com isso, ficou livre para escolher qualquer licença. Olhando as opções da época — GPL, licença Berkeley (BSD) e MIT —, ele achou todas cheias de juridiquês desnecessário para um código que havia escrito linha por linha. A decisão foi simplesmente declarar: domínio público.

No lugar de um texto de licença, Hipp colocou no cabeçalho dos arquivos uma bênção — uma pequena oração, no estilo "que você faça o bem e não o mal". Isso gerou controvérsia anos depois, mas o SQLite é reconhecido como software de código aberto de verdade. É um ótimo exemplo de que software livre e código aberto formam um espectro de práticas, e o domínio público é a forma mais permissiva de todas: não há restrição nenhuma de uso.

O modo como o projeto é mantido é igualmente peculiar. O código é aberto para ser lido e usado, mas fechado para contribuições externas: um núcleo minúsculo de pessoas escreve o SQLite, e pull requests da comunidade não são aceitos. Hipp explica com uma analogia afiada: aceitar um pull request não é "de graça" — é assumir o compromisso de manter, documentar, testar e dar suporte àquele código pelos próximos 25 anos. Ele chama isso de "um cachorrinho grátis". A equipe usa até a Regra de São Bento, do século VI, como código de conduta, com princípios de humildade, disciplina e compromisso de longo prazo. Estranho? Talvez. Mas o resultado é o banco mais implantado da história, sustentado por confiabilidade obsessiva e testes rigorosíssimos — o SQLite persegue níveis de cobertura de teste inspirados em padrões da aviação.

Vantagens e limitações: quando usar (e quando não usar)

Nenhuma ferramenta serve para tudo, e a própria documentação do SQLite é honesta sobre onde ele brilha e onde é melhor procurar outra coisa.

As vantagens são claras:

• Zero configuração: sem servidor, sem instalação, sem administração.
• Portabilidade: o banco inteiro é um arquivo que você copia à vontade.
• Leveza e velocidade: leituras são extremamente rápidas, muitas vezes na casa dos microssegundos, porque não há ida e volta pela rede.
• Confiabilidade: é compatível com ACID (garante integridade das transações) e testado de forma exaustiva.
• Simplicidade de desenvolvimento: permite entregar mais rápido, sem uma nova curva de aprendizado de infraestrutura.

As limitações merecem atenção igual. A própria documentação recomenda evitar o SQLite quando:

• Vários computadores acessam o mesmo banco pela rede, ao mesmo tempo, sem um servidor de aplicação no meio — é o cenário clássico cliente-servidor, para o qual MySQL e PostgreSQL existem.
• A aplicação tem altíssima concorrência de escrita, especialmente se exige múltiplos servidores. O SQLite permite apenas uma escrita por vez, o que pode ser um gargalo. Leituras simultâneas são tranquilas; muitas escritas simultâneas, não.
• O volume de dados é gigantesco. Um banco SQLite tem limite teórico de 281 terabytes, mais que suficiente para quase tudo — mas, como ele guarda o banco inteiro em um único arquivo, o limite real pode ser imposto antes pelo sistema de arquivos, que frequentemente aceita arquivos bem menores que isso.

A regra prática é simples. Precisa distribuir dados massivos pelo mundo, com muitos servidores e escritas concorrentes intensas? A maioria das aplicações de grande escala escolhe PostgreSQL ou um banco NoSQL, e faz sentido — não há forma nativa de fragmentar (shard) e replicar o SQLite para espalhar um conjunto de dados imenso pelo planeta. Mas para aplicativos mobile, sistemas embarcados, apps de desktop, testes, protótipos, e mesmo muitos SaaS de porte real, o SQLite não só serve como costuma ser a escolha mais elegante.

O banco de dados que resistiu ao tempo

Talvez o mais impressionante no SQLite seja a longevidade. Vinte e cinco anos após aquele problema com um sistema de controle de danos militar, ele continua ativo, mantido por um punhado de pessoas, de domínio público, sem investidores e sem hype. Periodicamente surge alguém prometendo ser "10 vezes mais rápido que o SQLite", e o próprio Richard Hipp diz acordar todo dia imaginando que aquele pode ser o último — que alguém finalmente fará algo melhor e a brincadeira acaba. Até agora, não aconteceu.

Para quem desenvolve, a lição do SQLite vai além da tecnologia. Ela mostra que uma ferramenta simples, bem projetada, testada à exaustão e feita com cuidado pode superar em alcance qualquer solução mais complexa. Da próxima vez que você abrir um app no celular, lembre-se: há uma boa chance de que, silenciosamente, um banco de dados nascido para um destróier da Marinha esteja guardando seus dados ali — sem servidor, sem instalação, num único arquivo.