PostgreSQL vs MySQL: qual usar no seu próximo projeto

Essa pergunta aparece em todo projeto novo. A resposta honesta é: na maioria dos projetos modernos, o PostgreSQL é a escolha certa. Mas “maioria” não é “todos”, e entender o porquê muda a qualidade das decisões que você vai tomar.

Vou explicar com base em projetos reais, não em benchmarks sintéticos.

O que cada um é, na prática

O MySQL ficou popular com o LAMP stack nos anos 2000. É rápido para leituras simples, bem suportado por hospedagens compartilhadas e tem décadas de tutoriais disponíveis. A grande maioria dos sistemas legados em PHP que você vai encontrar usa MySQL ou MariaDB.

O PostgreSQL é um banco objeto-relacional. Isso muda o comportamento prático: ele leva conformidade com o padrão SQL a sério, suporta tipos de dados avançados nativamente e tem um planejador de queries bem mais inteligente. A comunidade chama de “o banco de dados mais avançado do mundo de código aberto” e não é exagero.

Por que prefiro PostgreSQL em projetos novos

O primeiro motivo é confiabilidade. O MySQL historicamente teve problemas sérios com integridade transacional dependendo da engine usada. O MyISAM, que era padrão em versões antigas, não suportava transações. Com InnoDB melhorou, mas o PostgreSQL foi construído com ACID em mente desde o início. Em sistemas financeiros, ERP, qualquer coisa onde dado corrompido gera problema real, isso importa mais do que qualquer benchmark.

O segundo motivo são os tipos de dados. O MySQL tem VARCHAR e JSON. O PostgreSQL tem JSONB, que é JSON binário com suporte a índices e bem mais rápido para consultas em campos JSON. Tem UUID como tipo nativo, arrays nativos, RANGE types para intervalos de datas e números, e TSVECTOR para busca full-text.

Na prática, isso elimina gambiarras. Olha a diferença ao armazenar tags de um produto:

-- MySQL: tabela associativa ou JSON sem índice eficiente
SELECT p.name FROM products p
JOIN product_tags pt ON pt.product_id = p.id
JOIN tags t ON t.id = pt.tag_id
WHERE t.name = 'promoção';

-- PostgreSQL: array nativo com índice GIN
CREATE INDEX idx_products_tags ON products USING GIN(tags);
SELECT name FROM products WHERE tags @> ARRAY['promoção'];

Menos tabelas, menos joins, query mais simples. Esse padrão se repete em vários cenários ao longo de um projeto.

O terceiro motivo é a busca full-text. Para projetos de médio porte, manter Elasticsearch ou Meilisearch só para busca textual muitas vezes não faz sentido. O PostgreSQL resolve bem até um volume razoável:

ALTER TABLE articles ADD COLUMN search_vector TSVECTOR;

UPDATE articles SET search_vector =
  to_tsvector('portuguese', coalesce(title, '') || ' ' || coalesce(body, ''));

CREATE INDEX idx_articles_search ON articles USING GIN(search_vector);

SELECT title FROM articles
WHERE search_vector @@ plainto_tsquery('portuguese', 'banco de dados');

Não substitui Elasticsearch em escala, mas adia essa necessidade por bastante tempo. No Laravel a integração com PostgreSQL é transparente: basta trocar a connection no config e o Eloquent funciona normalmente.

Quando MySQL ainda faz sentido

Se o projeto precisa rodar em cPanel ou em infra que só oferece MySQL, não tem discussão. Use o MySQL e siga em frente. Não vale brigar com o ambiente.

Se o time tem anos de experiência operacional com MySQL, backups e replicação configurados e funcionando, trocar por PostgreSQL tem custo real. Às vezes o ganho técnico justifica, às vezes não. Depende do tamanho e da longevidade do projeto.

Para cargas com volume muito alto de writes simples e leituras triviais, MySQL com InnoDB ainda é excelente. Logging de eventos, analytics de clickstream, situações onde você insere milhões de linhas simples e faz poucas queries complexas.

Uma dica: se o contexto exige MySQL, prefira MariaDB. É o fork open source mantido por quem originalmente criou o MySQL, tem desempenho melhor em vários cenários e não tem a Oracle tomando decisões de licenciamento questionáveis.

O que muda mais do que o banco escolhido

Já vi sistemas lentos e problemáticos em PostgreSQL e sistemas rápidos e confiáveis em MySQL. O banco é uma ferramenta. O que determina o sucesso são o modelo de dados, os índices certos e queries que fazem sentido.

Índice nos campos que você filtra e faz join é básico:

CREATE INDEX idx_orders_status ON orders(status);
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

SELECT * em produção é erro que destrói performance mais do que a escolha do banco:

-- traz só o que a tela precisa
SELECT id, name, price, stock FROM products WHERE category_id = 1;

E EXPLAIN antes de sair otimizando na intuição:

EXPLAIN ANALYZE
SELECT o.id, c.name, o.total
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'pending';

O output do EXPLAIN mostra onde está o gargalo de verdade. Otimize baseado nisso, não em suposição.

Resumo direto

PostgreSQL para projetos novos onde você tem controle sobre a infra. MySQL ou MariaDB quando a infra já existe, a equipe tem expertise operacional estabelecida, ou o projeto tem restrições de hospedagem.

A discussão de PostgreSQL vs MySQL importa bem menos do que definir um modelo de dados limpo e não deixar queries N+1 destruírem a performance da aplicação. Mas se você tem a escolha, PostgreSQL é a certa para a maioria dos sistemas de negócio hoje.

Precisa de ajuda para escolher e estruturar a tecnologia certa para o seu projeto? Entra em contato pelo gabriels.dev.br.