A escolha do banco de dados parece grande demais para quem está começando, mas na prática dois nomes resolvem a maioria dos casos: SQLite e PostgreSQL. Os dois entendem SQL, a linguagem de consulta padrão, e guardam dados em tabelas. A diferença está em como funcionam e no tipo de projeto para o qual servem.
Se tabelas e comandos SQL ainda são novidade, leia primeiro banco de dados e SQL para iniciantes.
O que é o SQLite
O SQLite é um banco de dados embutido: não existe um programa servidor rodando à parte. Todo o banco fica num único arquivo (por exemplo, dados.db) que o seu programa abre e lê diretamente.
Características principais:
- Zero instalação de servidor. Em Python, o módulo sqlite3 já vem no pacote padrão.
- Um arquivo só. Fazer backup é copiar o arquivo; compartilhar é enviar o arquivo.
- Sem usuário e senha de banco. O acesso é controlado pelo acesso ao arquivo no sistema.
- Leve e rápido para volumes pequenos e médios.
Muitos aplicativos de celular e de computador usam SQLite por baixo, para guardar configurações e dados locais.
O que é o PostgreSQL
O PostgreSQL (muitas vezes chamado só de Postgres) é um banco cliente-servidor. Existe um programa servidor sempre rodando, e seus aplicativos se conectam a ele pela rede, com usuário e senha.
Características principais:
- Vários acessos ao mesmo tempo, inclusive com muitas gravações simultâneas.
- Controle de usuários e permissões detalhado.
- Recursos avançados, como tipos de dados variados, índices sofisticados, buscas em texto e transações robustas.
- Escala melhor conforme o sistema cresce.
- Exige instalação e manutenção, ou um serviço gerenciado na nuvem.
É um dos bancos mais usados em sistemas web profissionais, e é comum em serviços como o Supabase (veja Firebase ou Supabase).
As diferenças que mais importam
- Arquitetura: arquivo único (SQLite) contra servidor separado (PostgreSQL).
- Concorrência: o SQLite lê com facilidade em paralelo, mas escreve uma operação por vez. O PostgreSQL lida melhor com muitas escritas simultâneas.
- Segurança de acesso: no PostgreSQL você cria usuários com permissões diferentes. No SQLite, quem acessa o arquivo acessa tudo.
- Facilidade de começar: SQLite ganha de longe.
- Operação em produção: PostgreSQL exige configuração, backup e monitoramento (ou serviço gerenciado).
- Dados em vários servidores: se sua aplicação roda em mais de uma máquina, todas precisam acessar o mesmo banco. O arquivo do SQLite fica numa máquina só, o que complica. O PostgreSQL resolve naturalmente.
Quando o SQLite é a escolha certa
Pense em SQLite quando:
- você está aprendendo SQL;
- o projeto é um script, uma ferramenta pessoal ou um protótipo (veja ideias em scripts Python úteis para o dia a dia);
- o app roda localmente no celular ou no computador do usuário;
- o site tem poucos acessos de escrita e roda em um único servidor;
- você quer facilidade de backup e de cópia entre ambientes.
Quando migrar para o PostgreSQL
Considere o PostgreSQL quando:
- muitos usuários vão gravar dados ao mesmo tempo (cadastros, pedidos, comentários);
- o sistema vai rodar em várias instâncias ou servidores;
- você precisa de permissões diferentes para pessoas e programas diferentes;
- os dados são valiosos e exigem rotina de backup e recuperação mais controlada;
- o projeto vai crescer e precisa de recursos avançados.
Quem pretende construir algo que cresça deve ler também o app ficou lento com mais usuários.
Como não se arrepender da escolha
Algumas práticas deixam a troca futura menos dolorosa:
- Use SQL padrão sempre que possível, sem depender de truques exclusivos de um banco.
- Acesse o banco por uma camada única do código, em vez de espalhar consultas pelo projeto.
- Considere uma biblioteca de acesso a dados (ORM) que suporte vários bancos. Ela ajuda, mas não elimina todas as diferenças.
- Teste a migração com cópia dos dados antes de trocar de verdade.
- Faça backup antes de qualquer mudança, em qualquer banco.
Segurança em qualquer um dos dois
Independentemente do banco, valem as mesmas regras: use consultas parametrizadas para evitar injeção de SQL, não guarde senhas em texto puro e mantenha as credenciais fora do código, em variáveis de ambiente (veja variáveis de ambiente e arquivo .env). No PostgreSQL, nunca exponha a porta do banco diretamente à internet sem necessidade.
Um exemplo para visualizar a escolha
Pense em dois projetos. No primeiro, você cria um programa que guarda os gastos da sua família. Só você e mais uma pessoa usam, quase sempre em momentos diferentes. O SQLite resolve com folga: um arquivo, nenhuma configuração, backup copiando o arquivo.
No segundo, uma loja virtual recebe pedidos de vários clientes ao mesmo tempo, tem painel de administração, relatórios e integra com pagamento. Várias gravações simultâneas, permissões diferentes para cada pessoa e dados que não podem se perder: aqui o PostgreSQL faz mais sentido.
A diferença, no fundo, é o número de pessoas e programas escrevendo juntos e o quanto os dados valem para o negócio.
Resumo para decidir
Se você está começando, é um projeto pessoal ou tem poucos acessos, fique com o SQLite. Se o sistema terá muitos usuários gravando, mais de um servidor ou dados críticos de clientes, vá de PostgreSQL, de preferência gerenciado se você não quer cuidar da operação. Em ambos os casos, aprender SQL bem vale mais do que a escolha inicial do banco.