Neste artigo
“Qual banco de dados eu uso?” é uma das primeiras perguntas em um projeto novo, e a resposta padrão da internet é “PostgreSQL”. Ele é um ótimo banco, mas “melhor” depende do que você precisa. Este texto separa os motivos técnicos reais e os casos em que ele não é a escolha certa. Os fatos vêm da página oficial do projeto.
O que o projeto diz de si
O PostgreSQL se define como um sistema de banco de dados objeto-relacional de código aberto que usa e estende o SQL. Suas origens remontam a 1986, ao projeto POSTGRES na Universidade da Califórnia em Berkeley. Na versão 18, lançada em setembro de 2025, o projeto afirma conformidade com pelo menos 170 dos 177 recursos obrigatórios do SQL:2023 Core.
Onde ele se destaca
ACID. A página afirma conformidade com ACID desde 2001. Em termos práticos, uma transação não fica “meio salva” se o servidor cair no meio, o que importa para dinheiro, estoque e qualquer dado que não pode ficar inconsistente. Os detalhes de implementação estão na documentação de controle de concorrência (MVCC).
Tipos de dado. Além de inteiros, texto e datas, a lista oficial inclui arrays, intervalos, UUID, JSON/JSONB, XML e chave-valor (Hstore), além de tipos geométricos e tipos compostos ou customizados. Um campo JSONB resolve muitos casos de dado semiestruturado sem precisar de um banco NoSQL à parte.
Extensibilidade. A página diz que dá para definir tipos próprios, criar funções e até escrever código em outras linguagens (PL/pgSQL, Perl, Python e Tcl) sem recompilar o banco. O PostGIS, para dados geoespaciais, é citado como exemplo.
Onde pode não ser a escolha certa
- Protótipo de fim de semana ou app local: o SQLite é um arquivo só e dispensa servidor;
- Cache e sessão com leitura muito alta e simples: um armazenamento chave-valor dedicado, como o Redis, costuma servir melhor;
- Time que só conhece MySQL e projeto pequeno: a curva extra pode não compensar. Aqui é uma avaliação de contexto, não uma regra.
Não vou comparar velocidade com o MySQL. O desempenho depende da carga e da configuração, e a página do projeto não traz benchmarks.
Licença e custo
O PostgreSQL é gratuito e de código aberto, sem licença para pagar em produção. Hospedagem gerenciada em nuvem, claro, é cobrada à parte.
Migrar depois
Migrar de MySQL para PostgreSQL é possível, mas as funções, os tipos e algumas convenções mudam. Trate como um projeto à parte, não como troca de uma linha de configuração.
Para ver o Postgres em uso, o guia de API em Go com PostgreSQL monta um CRUD completo. E se o assunto é análise de grandes volumes, veja quando um banco colunar faz mais sentido.
O PostgreSQL não é “o banco perfeito”. É um bom padrão quando você quer integridade, tipos avançados e extensibilidade. A pergunta útil é o que o seu projeto específico precisa.
Leia também: Banco maduro não é banco sem bug, e eu gosto de lembrar disso com o caso do bug do WAL-reset que ficou pelo menos 16 anos escondido no SQLite.
