PostgreSQL ou MySQL: a transação muda o benchmark

O desempenho relativo de PostgreSQL e MySQL depende da transação medida. Para uma aplicação nova, PostgreSQL ganha peso quando consultas variadas, JSON pesquisável ou extensões atendem a requisitos concretos; MySQL ganha peso quando o esquema, o InnoDB e a operação já são conhecidos pela equipe. Nenhum resultado isolado de throughput decide a escolha.

Uma comparação útil reproduz a mesma regra de integridade, proporção de leituras e escritas, índices, volume de dados e caminho até a resposta. Para uma migração, soma-se a isso o custo de adaptar SQL, tipos e rotinas de operação. Se o teste muda a garantia exigida pela aplicação, passa a medir outra tarefa.

O isolamento muda o trabalho da transação

As configurações padrão já tornam diferentes dois testes aparentemente iguais. A documentação de isolamento do PostgreSQL define Read Committed como padrão: uma consulta comum vê os dados confirmados antes de começar, e outra consulta na mesma transação pode enxergar uma alteração confirmada nesse intervalo. Isso importa quando a aplicação lê um valor, decide o que escrever e consulta novamente antes de confirmar.

O manual de isolamento do InnoDB define Repeatable Read como padrão. Leituras consistentes na mesma transação usam o retrato fixado pela primeira leitura; buscas com bloqueio e alterações seguem outras regras. Uma busca por chave única pode bloquear apenas o registro encontrado, enquanto uma busca por intervalo pode bloquear também lacunas do índice. O formato da consulta modifica, portanto, a espera entre transações concorrentes.

Igualar o nome do nível de isolamento ajuda, mas a regra de negócio também precisa ser idêntica. Em um exemplo hipotético de reserva de estoque, as duas implementações devem impedir saldo negativo com controles de concorrência equivalentes, além de contar confirmações bem-sucedidas. Uma versão que apenas consulta o saldo sem proteger a atualização pode parecer rápida porque executa menos trabalho. Conflitos, novas tentativas e tempo de espera também entram no resultado: uma transação abortada não entrega o pedido ao usuário.

A carga decide se o benchmark serve

Uma busca por chave primária, uma consulta por intervalo e uma agregação percorrem caminhos diferentes. O mesmo vale para transações que apenas leem e para as que atualizam linhas, mantêm índices e confirmam alterações. A unidade de comparação deve ser uma operação completa da aplicação, com sua sequência de consultas e escritas; medir comandos soltos pode ocultar o custo da confirmação.

A apresentação sobre benchmarks no FOSDEM distingue conjunto de dados, consultas, atualizações, parâmetros, hardware e execuções com diferentes estados de cache. Seu exemplo de ClickBench reúne sistemas e configurações para consultas analíticas. Uma colocação nesse teste responde a uma pergunta sobre aquela carga, não sobre compras ou reservas transacionais.

Em um teste voltado à aplicação, mantenha comparáveis a distribuição dos dados, a concorrência, o armazenamento e a política de durabilidade. Registre throughput junto com a latência das operações críticas e a proporção de erros ou novas tentativas: uma média alta pode coexistir com confirmações lentas sob contenção. Se a base real exceder a memória disponível, testar apenas dados que cabem em cache dará peso excessivo ao acesso em memória.

JSON, índices e extensões mudam o desenho das consultas

Comparação entre a indexação de dados JSON no PostgreSQL e no MySQL para localizar um campo consultado.

A escolha para dados semiestruturados começa pelas perguntas que serão feitas aos documentos. A matriz de recursos do PostgreSQL lista JSONB, índices GIN, índices por expressão, extensões, replicação e manutenção. Essas opções podem servir a consultas que combinam atributos em JSON com dados relacionais, mas sua presença não revela o custo de uma consulta específica.

MySQL também dispõe de um tipo JSON e permite indexar valores extraídos em colunas geradas, além de valores de arrays. Se a aplicação filtra sempre o mesmo atributo, um índice direcionado pode bastar; filtros variados e combinações com outras tabelas podem exigir outro desenho. O plano de execução indica se o índice escolhido é usado, enquanto as escritas mostram o custo de mantê-lo.

Extensões do PostgreSQL têm valor quando resolvem uma necessidade identificada e estão disponíveis na hospedagem escolhida. Elas também entram no custo de atualização e de uma eventual migração. O mesmo raciocínio vale para funções específicas usadas no MySQL: quanto mais SQL depender de um comportamento particular, maior será o trabalho para reproduzi-lo em outro banco.

Réplicas ampliam a leitura, mas alteram a resposta

Uma escrita confirmada na origem MySQL ainda não aparece em uma réplica assíncrona consultada para leitura.

Na topologia tradicional, o manual de replicação do MySQL descreve a cópia assíncrona como padrão: a origem recebe as escritas e as leituras podem ser distribuídas entre réplicas. Como a alteração é aplicada na réplica depois, uma consulta enviada a ela pode retornar o estado anterior mesmo após a confirmação da escrita na origem.

Para um pedido que precisa aparecer imediatamente ao usuário, a rota de leitura faz parte da garantia da aplicação. Ler da origem após escrever pode atender a esse requisito; aceitar atraso nas réplicas pode ampliar a capacidade de leitura em outras telas. O ganho de throughput pertence, nesse caso, à topologia e à política de roteamento. Compará-lo com uma instância única do outro banco mistura capacidade agregada com desempenho individual.

A pergunta operacional para qualquer topologia com réplicas é qual atraso é aceitável, como detectar uma cópia defasada e de onde virá a leitura após uma escrita. Essas respostas afetam latência, disponibilidade e custo, mesmo quando o benchmark mostra muitas leituras por segundo.

A operação e a migração podem decidir o empate

Para uma aplicação nova, um requisito que sobrevive à troca de hardware pesa mais que um placar: uma regra de integridade, consultas JSON que se beneficiam de determinado índice ou uma topologia que tolera atraso nas leituras. Se os dois bancos atendem à carga com margem semelhante, o conhecimento da equipe e a hospedagem escolhida podem decidir.

O custo operacional inclui backup e restauração, atualização de versão, monitoramento, manutenção de índices e recuperação após falha. No PostgreSQL, isso inclui acompanhar rotinas como autovacuum; numa topologia MySQL com réplicas, inclui observar o atraso e a saúde das cópias. A equipe precisa conseguir operar os recursos efetivamente disponíveis no ambiente contratado.

Em uma migração, compare o benefício esperado com a reescrita de consultas, a conversão de tipos, a reconstrução de índices e a validação dos dados. As transações que motivaram a mudança devem permanecer corretas sob concorrência antes que latência ou throughput sejam considerados ganhos. Se a vantagem só aparece ao remover um índice, relaxar a integridade ou mudar a rota de leitura, a escolha envolve uma troca explícita de requisitos e de custo operacional.