SQLite vs PostgreSQL: embutido ou servidor?
SQLite é um banco de dados embutido e sem servidor armazenado em um único arquivo; PostgreSQL é um banco de dados cliente-servidor completo construído para concorrência e escala.
SQLite roda in-process sem servidor, tornando-o ideal para apps locais, testes, edge e cargas pequenas onde um único arquivo é suficiente. PostgreSQL roda como servidor com concorrência rica, roles, replicação e SQL avançado, adequado a sistemas de produção multiusuário. Eles atendem escalas diferentes em vez de competir diretamente: SQLite para simplicidade embutida, Postgres para produção concorrente.
| SQLite | PostgreSQL | |
|---|---|---|
| Arquitetura | Embutido (in-process) | Cliente-servidor |
| Configuração | Zero config (um arquivo) | Servidor + roles |
| Concorrência | Escritores limitados | Alta, MVCC |
| Recursos | SQL básico | Ricos (extensões, tipos) |
| Melhor para | Apps locais, testes, edge | Produção concorrente |
Caso de uso e escala
SQLite brilha para apps desktop e mobile, CLIs, protótipos e como banco de dados de teste rápido, sem serviço para gerenciar. Postgres é a escolha quando você tem escritores concorrentes, múltiplos serviços ou precisa de replicação e recursos avançados. Alguns times desenvolvem contra SQLite e implantam em Postgres, mas atenção às diferenças de dialeto SQL.
Em CI
SQLite não precisa de service container, então os testes são rápidos e herméticos. Postgres roda como service container para testes com paridade de produção. Em runners gerenciados, o SQLite mantém os jobs de teste enxutos enquanto os testes de paridade com Postgres se beneficiam de uma inicialização de container mais rápida.
O veredito
Cargas embutidas, de usuário único ou de testes herméticos: SQLite, com zero overhead operacional. Sistemas de produção concorrentes e multi-serviço: PostgreSQL. Misturá-los (SQLite em dev, Postgres em prod) é comum, mas arrisca desvio de dialeto, então prefira testar contra seu engine de produção.