O que é SQLite? Guia do banco de dados embutido

SQLite É um Banco de Dados Dentro do Seu Programa

A maioria dos bancos que você já ouviu falar — MySQL, Postgres, SQL Server — roda como um programa à parte. Você sobe um servidor, ele fica escutando numa porta, e sua aplicação se conecta pela rede para fazer as consultas. O SQLite joga esse modelo todo no lixo.

O SQLite é uma biblioteca. Você linka ela no seu programa e ganha um banco de dados SQL que vive num único arquivo em disco. Sem servidor, sem porta, sem daemon, sem pg_ctl start. Sua aplicação abre um arquivo, e esse arquivo é o banco de dados.

sqlite3 mydata.db

Esse comando abre (ou cria) um arquivo chamado mydata.db e te entrega um prompt SQL. Tudo o que você fizer ali — tabelas, linhas, índices — vai parar dentro desse único arquivo. Copiou ele pra outra máquina? O banco vai junto. Apagou? O banco se foi.

Uma passada rápida pelo SQL

O SQL em si é igual ao de qualquer outro banco. Se você já mexeu com algum outro SGBD, praticamente tudo vai parecer familiar:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

SQL padrão — CREATE TABLE, INSERT, SELECT, ORDER BY. O SQLite suporta as partes do padrão SQL que você de fato usa no dia a dia, além de recursos modernos como CTEs, funções de janela (window functions) e funções para JSON. As diferenças em relação ao Postgres ou MySQL aparecem principalmente nos tipos de dados e em algumas peculiaridades de sintaxe, mas a gente entra nesses detalhes mais adiante.

O que significam de fato "embutido" e "sem servidor"

Duas palavras aparecem o tempo todo quando o assunto é SQLite. Vale a pena deixar claro o que cada uma quer dizer.

Embutido quer dizer que o SQLite roda dentro do mesmo processo da sua aplicação. Não existe um processo separado de banco de dados. Quando seu script Python chama sqlite3.connect("data.db"), o motor SQL está rodando dentro do próprio processo do Python, lendo e escrevendo direto no arquivo.

Sem servidor (ou serverless) significa que não há servidor para instalar, configurar, rodar, proteger ou fazer backup. Compare o que é preciso fazer para começar a usar cada banco:

• Postgres: instalar o Postgres, subir o serviço, criar um usuário, criar um banco, ajustar o pg_hba.conf, conectar via TCP.
• SQLite: abrir um arquivo.

É essa a diferença, em resumo. Menos poder, muito menos burocracia.

O banco inteiro cabe em um único arquivo

Essa é a parte que costuma surpreender. O formato do arquivo é documentado e estável — um arquivo .db (ou .sqlite, ou .sqlite3, a extensão é só convenção) que você pode:

• Mandar por e-mail para um colega.
• Versionar no git (os pequenos, claro).
• Copiar com cp para fazer um backup instantâneo.
• Abrir em qualquer ferramenta de SQLite, em qualquer sistema operacional.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

Esse arquivo único guarda suas tabelas, seus índices, seu schema e seus dados. Bancos SQLite em disco são idênticos byte a byte em Windows, macOS, Linux, iOS e Android. O formato é tão estável que a Biblioteca do Congresso dos EUA o recomenda para preservação de dados a longo prazo.

Onde você já usa SQLite hoje

É quase certo que existem centenas de bancos SQLite no aparelho em que você está lendo isto agora. Ele está por trás de:

• Armazenamento do sistema no iOS e Android, além de muitos apps nas duas plataformas.
• Firefox, Chrome e Safari (histórico, favoritos, cookies).
• macOS (Mail, Fotos, o dock).
• A maioria dos apps de desktop Linux que precisam guardar dados localmente.
• Skype, WhatsApp, Signal — histórico de conversas.
• Catálogos do Adobe Lightroom, metadados do Dropbox, bibliotecas da Steam.

Já o chamaram do banco de dados mais usado no mundo, e provavelmente é verdade. O motivo é simples: quando uma aplicação precisa de armazenamento local estruturado, o SQLite é o caminho de menor resistência.

O que o SQLite não é

Ele não é um banco cliente-servidor. Dois programas em máquinas diferentes não conseguem se conectar ao mesmo banco SQLite pela rede — não existe camada de rede para se conectar. Se você precisa disso, vai querer Postgres ou MySQL.

Ele não foi feito para alta concorrência de escrita. O SQLite usa travamento em nível de arquivo (com algumas otimizações espertas no modo WAL); então, embora muitos leitores possam trabalhar em paralelo, só um escritor consegue fazer commit por vez. Para um app de usuário único ou um site com pouco tráfego, isso não é problema. Para um SaaS multi-tenant recebendo milhares de escritas por segundo, é a ferramenta errada.

Ele não gerencia usuários nem permissões. Acesso ao banco é acesso ao arquivo — quem consegue ler o arquivo lê os dados. Isso é tranquilo para um app que tem o próprio arquivo de banco. Não é tranquilo num ambiente compartilhado multi-tenant.

Por que escolher o SQLite

A troca é simplicidade em troca de uma margem de escala que talvez você nunca precise:

• Zero configuração. Nenhum serviço para rodar. Sem divergência de versão entre dev e produção. Não tem aquele "o banco caiu" porque não existe servidor de banco.
• Rápido. Para a maioria das cargas de trabalho, principalmente as voltadas para leitura, o SQLite é mais rápido que um banco em rede — não tem round-trip de socket a cada query.
• Confiável. Ele é testado de forma obsessiva. O projeto SQLite tem muito mais código de teste do que código-fonte, e o formato é estável desde 2004.
• Domínio público. Livre para qualquer uso, inclusive comercial. Nenhuma licença para ler.
• Portátil. Um arquivo, todas as plataformas.

Para aplicativos locais, protótipos, dispositivos embarcados, ferramentas de linha de comando, suítes de teste, scripts de análise de dados e sites de pequeno e médio porte, o SQLite muitas vezes é o padrão correto — não um degrau a caminho de um banco "de verdade".

A seguir: SQLite vs MySQL

Uma pergunta natural a essa altura é como o SQLite se compara aos servidores de banco sobre os quais você provavelmente já ouviu mais falar. Vamos começar pelo MySQL — onde cada um leva vantagem e como saber qual encaixa melhor no projeto que você tem em mãos.