SQLite vs Postgres: qual banco escolher e quando

Dois bancos de dados, duas filosofias diferentes

SQLite e PostgreSQL falam SQL, guardam dados relacionais e dão conta de aplicações reais. Passou disso, são feitos para mundos bem diferentes.

• SQLite é uma biblioteca. Ele roda dentro do processo da sua aplicação e lê de um único arquivo .db no disco. Sem servidor, sem porta, sem usuário para configurar.
• PostgreSQL é um servidor. Roda como um processo próprio, escuta numa porta de rede, e sua aplicação se conecta a ele como cliente.

Praticamente toda a diferença entre SQLite e Postgres — concorrência, deploy, rigidez de tipos, performance — vem dessa decisão arquitetural. Vale manter isso na cabeça enquanto a gente avança.

Arquitetura: dentro do processo vs cliente/servidor

Abrir um banco SQLite é literalmente abrir um arquivo:

-- SQLite: o banco de dados é apenas este arquivo.
CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT);
INSERT INTO notes (body) VALUES ('olá de um arquivo');
SELECT * FROM notes;

Não tem daemon pra subir, nada de editar pg_hba.conf, nem porta pra expor. Seu app simplesmente carrega a biblioteca do SQLite, abre o notes.db e já começa a rodar as queries. Fazer deploy é literalmente "copiar o arquivo".

Já com o Postgres a história é outra:

# Inicie o servidor (uma vez, como administrador):
sudo systemctl start postgresql

# Em seguida, conecte-se a partir do seu aplicativo:
psql -h localhost -U alice -d mydb

Sua aplicação conversa com um processo separado — normalmente via TCP, às vezes por socket Unix. Essa camada extra cobra um preço: tempo de setup e um round-trip de conexão por query. Em troca, você ganha acesso pela rede, autenticação multiusuário e escritas concorrentes de verdade.

Concorrência: o ponto que decide tudo

Geralmente é aqui que a escolha entre sqlite ou postgres se resolve. O SQLite serializa as escritas: a cada instante, apenas um writer detém o lock do arquivo do banco, e os demais ficam na fila. As leituras rodam em paralelo (principalmente no modo WAL), mas as escritas saem uma de cada vez.

Já o Postgres usa MVCC (controle de concorrência multiversão) e locks no nível da linha. Várias transações conseguem gravar em linhas diferentes ao mesmo tempo, sem travar umas às outras.

Na prática:

• Um blog com 50 leitores por segundo e um autor publicando de vez em quando? SQLite resolve tranquilo.
• Um checkout de e-commerce com centenas de usuários atualizando estoque ao mesmo tempo? Postgres.
• O cache local de um app mobile? SQLite, sem discussão.
• Um backend SaaS multi-tenant com dezenas de workers em background? Postgres.

O sqlite WAL mode (PRAGMA journal_mode = WAL;) melhora bastante a história de concorrência do SQLite — leitores deixam de bloquear escritores —, mas não muda a regra de um único writer por vez.

Sistema de tipos: flexível vs rígido

O Postgres é rígido. Uma coluna declarada como INTEGER rejeita strings, ponto final:

-- Postgres
CREATE TABLE t (n INTEGER);
INSERT INTO t (n) VALUES ('not a number');
-- ERRO: sintaxe de entrada inválida para o tipo integer

SQLite, por padrão, trabalha com type affinity — uma sugestão, não uma regra rígida. O mesmo insert acaba passando:

CREATE TABLE t (n INTEGER);
INSERT INTO t (n) VALUES ('não é um número');
SELECT n, typeof(n) FROM t;

A string fica ali, tranquila, dentro de uma coluna INTEGER. O SQLite armazenou como texto, sem reclamar. Essa flexibilidade foi uma decisão de design proposital — ótima para protótipos rápidos, perigosa para esquemas que precisam durar.

A partir do SQLite 3.37, dá pra usar tabelas STRICT, que se comportam de um jeito bem mais parecido com o Postgres:

CREATE TABLE t (n INTEGER) STRICT;
-- INSERT INTO t (n) VALUES ('não é um número');  -- agora é um erro
INSERT INTO t (n) VALUES (42);
SELECT n, typeof(n) FROM t;

Se você está começando um projeto novo no SQLite, use STRICT. Isso elimina toda aquela classe de surpresas do tipo "por que tem uma string na minha coluna numérica?".

Recursos disponíveis

O Postgres tem mais de quase tudo: tipos de dados (arrays, ranges, geométricos, de rede, enums customizados), linguagens procedurais (PL/pgSQL, PL/Python), full-text search com ranking, views materializadas, particionamento de tabelas, replicação, segurança baseada em papéis, e um ecossistema profundo de extensões (PostGIS, TimescaleDB, pgvector).

O SQLite cobre o essencial e ainda joga alguns recursos legais para o tamanho que se propõe: funções JSON, full-text search via FTS5, índices R-Tree, window functions, CTEs e colunas geradas. O que ele deixa de fora é tudo que pressupõe um servidor: usuários, papéis, replicação, acesso pela rede.

Um modelo mental rápido para decidir entre sqlite ou postgres:

• Precisa de GIS, busca vetorial ou replicação? Postgres.
• Precisa embarcar um banco dentro de um app iOS? SQLite.
• Precisa dos dois? Muitos times desenvolvem e testam no SQLite e fazem deploy no Postgres — só que essa combinação pode te morder por causa das diferenças de sintaxe (veja a seguir).

Diferenças de sintaxe que você vai encontrar na prática

A maior parte do SQL do dia a dia é idêntica. As diferenças se concentram em schema, tipos e algumas funções nativas:

-- Chave primária auto-incrementável
-- SQLite:
CREATE TABLE users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT);
-- Postgres:
CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
-- ou, no Postgres moderno:
CREATE TABLE users (id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT);

-- Timestamp atual
-- SQLite:  CURRENT_TIMESTAMP   (retorna texto)
-- Postgres: NOW()              (retorna timestamp)

-- Tipo booleano
-- SQLite:  não há BOOLEAN real; use INTEGER 0/1
-- Postgres: BOOLEAN com TRUE/FALSE

Se você desenvolve em SQLite e coloca em produção no Postgres, vale a pena manter um ORM ou uma ferramenta de migração entre você e o SQL puro — caso contrário, essas diferenças vazam para dentro da sua aplicação.

Performance, sem enrolação

"Mais rápido" depende da pergunta. Para um único processo fazendo leituras e gravações pequenas, é difícil bater o SQLite — não tem ida e volta de rede, nem parsing de protocolo, nem conexão de cliente. Em benchmarks com um único cliente, o SQLite costuma passar na frente do Postgres em consultas simples.

Agora, se você adiciona vários escritores simultâneos, datasets grandes que precisam de execução paralela de consultas, ou planos de consulta complexos que se beneficiam do planejador maduro do Postgres, aí o Postgres assume a liderança. Ele também escala verticalmente (máquinas maiores, mais núcleos) de um jeito que o SQLite simplesmente não foi projetado para fazer.

O resumo honesto sobre sqlite vs postgres performance: o SQLite é rápido para o que ele se propõe. O Postgres é rápido para o que ele se propõe. A escolha vem do formato da sua carga de trabalho, não da manchete do benchmark.

Guia rápido: quando usar SQLite ou Postgres

Vá de SQLite quando:

• Os dados moram ao lado de uma única aplicação — desktop, mobile, embarcado, ferramenta de linha de comando.
• As gravações vêm de um único processo ou de poucos processos.
• Você quer deploy sem configuração nenhuma.
• Está prototipando e quer focar no schema, não na infraestrutura.

Vá de Postgres quando:

• Vários servidores de aplicação ou workers escrevem no banco.
• Você precisa de acesso via rede a partir de muitos clientes.
• Você precisa de recursos avançados: roles, replicação, GIS, tipos customizados, stored procedures.
• O banco é o repositório central e duradouro de um serviço em produção.

Um caminho comum: começar um projeto pequeno no SQLite e migrar para o Postgres se e quando o perfil de tráfego exigir. A migração não sai de graça, mas é uma operação conhecida — e a maioria dos projetos nunca chega a precisar dela.

A seguir: quando o SQLite é a escolha certa

A comparação acima mostra os trade-offs. A próxima página entra mais a fundo no lado positivo do SQLite — as cargas de trabalho onde ele não é só bom o suficiente, mas de fato a ferramenta certa, além dos sinais de alerta que indicam que você já passou do ponto e precisa trocar.