Quando usar SQLite: casos de uso e limitações

A pergunta central

SQLite não é uma versão reduzida do Postgres. É uma ferramenta com um formato diferente. O banco inteiro é um arquivo em disco, e sua aplicação conversa com ele através de uma biblioteca linkada no mesmo processo — sem servidor, sem rede, sem usuários. Esse desenho faz do SQLite uma escolha brilhante para certas tarefas e ruim para outras.

A pergunta decisiva quase nunca é "será que o SQLite é rápido o suficiente?" (geralmente é). É "o formato da minha aplicação combina com aquilo em que o SQLite é bom?". Duas coisas pesam mais nessa decisão: onde os dados ficam, e quantas coisas escrevem neles ao mesmo tempo.

Quando usar SQLite: quando os dados moram junto com a aplicação

O SQLite brilha quando o banco pertence a uma única aplicação rodando numa única máquina. O arquivo fica ao lado do seu código, a aplicação abre ele direto, e essa é a arquitetura inteira.

-- Um esquema típico de "os dados vivem com o app":
-- o armazenamento local de um app de anotações para desktop.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Compras', 'leite, pão, café'),
    ('Ideias',  'roteiro do tutorial de sqlite');

SELECT id, title, created FROM notes;

Esse esqueminha de schema poderia ser o backend inteiro de um app de verdade. Alguns cenários onde esse padrão cai como uma luva:

• Apps desktop e mobile. Todo app de iOS e Android que precisa de armazenamento local estruturado usa SQLite por baixo dos panos. Firefox, Chrome e a maioria dos navegadores também.
• Ferramentas de linha de comando. git, gerenciadores de pacotes e gerenciadores de dotfiles usam bancos de dados embarcados.
• Dispositivos embarcados. Roteadores, carros, aviões — qualquer coisa que precise de um banco de dados ocupando poucas centenas de kilobytes.
• Suítes de testes. Criar um arquivo SQLite novinho (ou um banco :memory:) por teste é mais rápido e mais isolado do que subir um Postgres.

Se seus dados não precisam ser compartilhados entre várias máquinas, o SQLite provavelmente é a resposta certa.

SQLite para aplicações web com muita leitura

O SQLite lida com leituras de forma espetacular. Vários leitores simultâneos, sem disputa, consultas em microssegundos para buscas indexadas. Se seu site é majoritariamente gente consumindo conteúdo — blogs, documentação, sites institucionais, pequenos dashboards de SaaS — o SQLite vai aguentar tranquilo, muitas vezes melhor do que um Postgres acessado pela rede, justamente porque não tem o round-trip.

-- Tabela de posts de um blog.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Olá, Mundo', 'Primeiro post.', '2024-01-01'),
    ('sqlite-rocks', 'Por que SQLite',  'Banco de dados em arquivo único.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

O detalhe está nas escritas. O SQLite serializa as escritas — só um writer consegue segurar o lock por vez. Num blog com alguns autores, isso é imperceptível. Já num app de chat com milhares de usuários mandando mensagens por segundo, vira um gargalo.

O modo WAL (write-ahead logging, que vamos ver mais pra frente) eleva bastante esse teto, permitindo que leitores e o writer trabalhem em paralelo. Existe um monte de site em produção servindo milhões de requisições por dia rodando em SQLite + WAL.

Use SQLite para caches locais e dados temporários

Sempre que você precisar de armazenamento local estruturado — algo além de um arquivo JSON, mas aquém de um servidor de banco completo — o SQLite é difícil de bater.

-- Uma tabela de cache para um cliente HTTP.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Logs, buffers de analytics, staging de ETL, feature stores de machine learning, índices de IDE — todos são lares naturais para o SQLite. O arquivo é portátil, a linguagem de consulta é SQL completo e não há servidor para ficar de babá.

Quando não usar SQLite: muitos writers simultâneos

Essa é a limitação que pega a galera de surpresa. O SQLite usa um lock de escrita no nível do banco: um writer por vez, ponto final. Se dois processos tentarem fazer insert no mesmo instante, um deles espera.

Para a maioria das aplicações isso não faz diferença — as escritas são raras e rápidas. Mas se a sua carga de trabalho se parece com:

• Um SaaS multi-tenant com milhares de usuários escrevendo ao mesmo tempo,
• Uma fila de mensagens ou log de eventos de alta vazão,
• Um backend de jogo em tempo real ou chat com mudanças de estado constantes,

aí o SQLite vira gargalo. Postgres e MySQL usam lock no nível da linha e foram feitos justamente para esse cenário. Vá de um deles.

-- O erro que você verá quando os escritores se acumularem:
Error: database is locked

Se você está vendo isso sob carga normal, o SQLite é a ferramenta errada — não é um bug pra contornar.

Não use SQLite entre várias máquinas

O SQLite é uma biblioteca que roda dentro do processo. A aplicação lê e escreve direto no arquivo, ou seja, o arquivo precisa estar em um disco que a aplicação consiga acessar via read() e write() com chamadas normais de sistema de arquivos.

Isso elimina:

• Vários servidores de aplicação atrás de um load balancer, todos querendo compartilhar o mesmo banco. (Sistemas de arquivos em rede como NFS até funcionam na teoria, mas corrompem o arquivo sob carga. Não faça isso.)
• Funções serverless, onde cada invocação roda em uma máquina diferente.
• Pods do Kubernetes que precisam compartilhar um banco — a menos que seja um deployment de pod único com volume persistente.

Se a sua arquitetura tem mais de um processo, em mais de uma máquina, escrevendo no banco, você precisa de um banco cliente-servidor. Esse é o limite.

Não use SQLite quando precisar de usuários no banco

O SQLite não tem nenhum conceito de usuários, roles ou permissões. O banco é um arquivo — quem consegue ler o arquivo lê tudo; quem consegue escrever, escreve tudo. Controle de acesso é responsabilidade do sistema operacional.

Pra um app desktop de usuário único, beleza. Mas em um sistema multi-tenant, onde pessoas diferentes precisam de privilégios diferentes dentro do banco, vá de Postgres ou MySQL.

Checklist rápido de decisão

Passe por essa lista. Se a resposta for "sim" pra tudo, o SQLite provavelmente é uma ótima escolha:

• O banco fica na mesma máquina da aplicação.
• Um processo (ou alguns poucos, em sua maioria lendo) conversa com ele.
• O volume total de dados cabe tranquilamente em um disco — terabytes tudo bem, mas ainda é um disco só.
• Você não precisa de permissões de usuário no nível do banco.
• Escritas concorrentes são ocasionais, não o grosso da carga.

Se qualquer resposta for "não", olhe pra Postgres ou MySQL. As próximas duas páginas comparam cada um diretamente.

O que levar daqui

• O SQLite é a escolha certa quando o banco é local à aplicação: desktop, mobile, embarcado, ferramentas de linha de comando, suítes de teste, sites com muita leitura, caches locais.
• É de nível produção — bilhões de dispositivos rodam com ele. As limitações são arquiteturais, não de qualidade.
• Deixe pra lá quando precisar de muitos writers concorrentes, acesso entre múltiplas máquinas ou permissões por usuário dentro do banco.

A seguir: instalando o SQLite

Chega de teoria. A próxima página mostra como colocar o SQLite na sua máquina — ele já vem no macOS e na maioria das distros Linux, e é um download único no Windows — e como conferir a instalação pela linha de comando.