O debate PostgreSQL vs MySQL parece antigo, mas continua sendo uma das decisões de arquitetura com maior custo de reversão em um SaaS. Banco relacional não se troca como uma biblioteca: schema, queries, ORM, rotinas de backup e a cultura do time acabam moldados ao motor escolhido. Este comparativo evita torcida e foca em como cada banco funciona de verdade, onde ele ganha e onde cobra a conta.
A premissa é comparar PostgreSQL com MySQL usando o engine InnoDB, em versões atuais e suportadas. Antes de fechar qualquer decisão, valide os recursos específicos na documentação da versão que você pretende rodar em produção.
Arquitetura: armazenamento e concorrência
A diferença mais profunda na comparação PostgreSQL vs MySQL está em como cada um organiza os dados em disco e controla concorrência. Isso afeta desempenho, manutenção e até a forma como você escolhe chaves primárias.
PostgreSQL: heap, MVCC e vacuum
O PostgreSQL armazena as linhas em um heap e implementa MVCC mantendo versões de tupla no próprio heap. Um UPDATE cria uma nova versão da linha, e as versões antigas são removidas depois pelo autovacuum. O benefício é leitura sem bloqueio de escrita. O custo é operacional: autovacuum mal ajustado gera bloat de tabelas e índices, e isso exige monitoramento.
Outro ponto é o modelo de processo por conexão. Em aplicações com muitas conexões curtas, o uso de um pooler como o PgBouncer é prática comum, e não opcional.
MySQL com InnoDB: índice clusterizado
No InnoDB, a tabela é organizada como um índice clusterizado pela chave primária. A busca por PK é muito eficiente, mas toda chave secundária carrega o valor da PK. Resultado: uma PK grande ou aleatória, como um UUID v4 em texto, infla os índices e provoca fragmentação nas inserções. O MVCC usa undo logs, e o servidor trabalha com modelo de thread por conexão.
Recursos que mudam a modelagem
Na prática, o que pesa no dia a dia de um SaaS é o conjunto de recursos disponíveis. Aqui o PostgreSQL costuma oferecer mais opções nativas, enquanto o MySQL compensa com simplicidade e familiaridade.
- JSON: o PostgreSQL tem JSONB com índices GIN, o que permite consultar documentos semiestruturados com bom suporte do planner. O MySQL tem tipo JSON, e a indexação normalmente passa por colunas geradas.
- Índices parciais e de expressão: nativos no PostgreSQL, úteis para indexar só o que importa, como assinaturas ativas.
- Extensões: PostGIS para geodados e pgvector para busca vetorial são exemplos do ecossistema PostgreSQL.
- Row-level security: o PostgreSQL permite políticas por linha, relevante para isolamento multi-tenant. O MySQL não tem recurso equivalente nativo.
- DDL transacional: no PostgreSQL, a maioria dos comandos de DDL pode rodar dentro de uma transação e ser revertida, o que simplifica migrations. No MySQL, comandos de DDL causam commit implícito.
- SQL moderno: CTEs e window functions estão disponíveis no MySQL desde a série 8.0, reduzindo a antiga distância nesse ponto.
Exemplo de modelagem multi-tenant com JSONB e índice parcial no PostgreSQL:
CREATE INDEX idx_events_payload ON events USING GIN (payload jsonb_path_ops);
CREATE INDEX idx_subs_active ON subscriptions (customer_id) WHERE status = 'active';
SELECT id FROM events WHERE payload @> '{"plan":"pro"}';Replicação, alta disponibilidade e escala
O PostgreSQL oferece streaming replication (física) e replicação lógica. A alta disponibilidade com failover automático normalmente depende de ferramentas externas, como o Patroni, ou de um serviço gerenciado. Para escala horizontal, as opções passam por particionamento nativo ou extensões como o Citus, cada uma com trade-offs próprios.
O MySQL tem uma tradição forte em replicação baseada em binlog, além de Group Replication e InnoDB Cluster, com o MySQL Router na frente. Para sharding em larga escala, o Vitess é uma referência conhecida. Em compensação, o desenho operacional de clusters exige disciplina em topologia e tratamento de lag.
Se você pretende rodar o banco dentro de um cluster, lembre que workloads stateful pedem operadores maduros, storage confiável e estratégia de backup testada. Vale ler antes o comparativo Orquestração de containers: Kubernetes, Swarm ou Nomad? para entender o custo operacional da plataforma.
Quando escolher cada um
PostgreSQL tende a ser melhor quando
- o domínio exige consultas complexas, relatórios e integridade rigorosa;
- você precisa de JSONB, geodados, busca vetorial ou row-level security;
- as migrations frequentes se beneficiam de DDL transacional;
- o roadmap pode incluir extensões que evitam adicionar outro serviço.
MySQL tende a ser melhor quando
- o workload é dominado por leituras e escritas simples por chave primária;
- o time já tem experiência profunda em operação e tuning de InnoDB;
- o ecossistema legado (CMS, ERPs, aplicações existentes) já pressupõe MySQL;
- há plano claro de sharding com Vitess ou ferramenta equivalente.
Critérios de decisão para o seu time
Na decisão PostgreSQL vs MySQL, o fator mais subestimado é a competência operacional disponível. Um banco tecnicamente superior para o seu caso, mas que ninguém sabe operar, vira passivo. Considere quem fará tuning, monitoramento de vacuum ou de replication lag, testes de restore e upgrades de versão.
Esse ponto conversa com a decisão de montar equipe própria ou contratar parceiros, tema do framework de outsourcing de desenvolvimento ou time interno para founders. Um serviço gerenciado reduz a carga, mas traz custo recorrente, limites de extensões e dependência do provedor.
Também avalie licenciamento: o PostgreSQL usa licença permissiva própria, enquanto o MySQL é distribuído sob GPL com opção comercial da Oracle. Para a maioria dos SaaS isso não bloqueia nada, mas merece uma leitura jurídica se você distribui o banco embarcado no produto.
Por fim, faça uma prova de conceito com dados e queries reais. Rode o EXPLAIN ANALYZE nas suas consultas críticas, simule carga com o padrão de acesso do produto e meça. Benchmarks genéricos de internet raramente representam o seu workload.
Conclusão
Não existe vencedor universal em PostgreSQL vs MySQL. O PostgreSQL entrega mais recursos nativos e flexibilidade de modelagem, ao custo de atenção a vacuum e conexões. O MySQL oferece um modelo previsível e um ecossistema de replicação consolidado, com menos recursos avançados nativos. Escolha pelo domínio do produto, pela competência do time e pelo custo operacional, valide com dados reais e documente a decisão como um registro de arquitetura.
