MySQL vs PostgreSQL: O Que Realmente Importa na Escolha?
Recentemente, realizei um estudo detalhado sobre as diferenças entre o MySQL e o PostgreSQL, tentando entender qual deles se encaixaria melhor em um novo projeto de ERP online. Como qualquer decisão técnica, essa escolha precisava ir além do "o que é mais popular" e realmente considerar o cenário real de uso.
Logo de cara, o PostgreSQL parecia imbatível: robusto, escalável e recheado de funcionalidades avançadas. Dentre os principais pontos positivos, destacavam-se:
- Melhor suporte a transações complexas (ACID mais confiável);
- JSONB para dados não estruturados;
- Índices avançados (GIN, BRIN, GiST);
- Consultas analíticas mais sofisticadas (CTEs recursivas, Window Functions);
- Replicação e escalabilidade eficientes;
- Melhor controle de concorrência (MVCC bem implementado).
Já o MySQL se destacava por sua velocidade em leituras, otimização de armazenamento e menor consumo de recursos. Porém, ainda perdia para o PostgreSQL quando o assunto era operações complexas e gerenciamento de concorrência.
Diante disso, a decisão parecia óbvia: PostgreSQL. Mas... será que era mesmo?
Comparando MySQL 8 vs PostgreSQL
| Recurso | MySQL 8 | PostgreSQL |
|---|---|---|
| ACID e MVCC | Melhorado, mas ainda tem problemas com lock contention | MVCC mais eficiente, melhor concorrência |
| Suporte a JSON | Sim, mas menos eficiente que PostgreSQL (JSON) | JSONB (mais rápido e indexável) |
| Índices | B-Tree, Hash, Spatial, Full-Text | B-Tree, Hash, GIN, BRIN, GiST, Full-Text |
| Consultas Analíticas | Suporte melhorado, mas menos flexível | Melhor suporte (CTEs, Window Functions, recursion) |
| Particionamento de Tabelas | Suporte aprimorado no MySQL 8 | Melhor gerenciamento de particionamento |
| Escalabilidade Horizontal | Replicação nativa e suporte ao InnoDB Cluster | Melhor replicação, suporte a sharding nativo |
| Segurança | Suporte a autenticação via roles e SSL | Melhor controle granular de permissões |
O Cenário Real: Onde a Decisão Mudou
O ERP em questão é amplamente comercializado, com mais de mil clientes ativos. Cada cliente tem um banco de dados próprio, com cerca de 500 tabelas e sem uso de triggers ou procedures. Além disso, o tamanho médio das bases é de 5GB, e cada servidor hospedará até 150 bancos de clientes.
A partir desse cenário, dois fatores críticos surgiram:
- Grande quantidade de bancos de dados por servidor;
- Múltiplas tabelas em cada banco.
Com essa configuração, a escolha do SGBD precisava levar em conta não apenas os benchmarks gerais, mas como cada tecnologia se comportaria sob essa carga específica.
1. Gerenciamento de Múltiplos Bancos de Dados
- O PostgreSQL trata cada banco como uma entidade isolada, com seu próprio cache, conexões e catálogo. Isso significa mais consumo de memória e CPU, reduzindo a eficiência quando há muitos bancos em uma mesma instância.
- Já o MySQL compartilha cache e conexões entre bancos, reduzindo a sobrecarga e otimizando o uso de recursos.
- Em um teste comparativo, PostgreSQL consumiu 35% mais memória do que MySQL ao gerenciar múltiplos bancos pequenos com alto número de conexões simultâneas.
2. Consumo de Memória e CPU
- De acordo com benchmarks públicos, o PostgreSQL consome, em média, 30-50% mais RAM do que o MySQL para workloads similares.
- O gerenciamento de conexões do PostgreSQL também tem maior overhead, resultando em uso de CPU até 40% maior em cenários de múltiplos bancos ativos simultaneamente.
- Para um servidor com 150 bancos, essa diferença se traduz em um custo maior de infraestrutura.
3. Eficiência Transacional e Estrutura de Armazenamento
- Como o projeto não utiliza triggers nem stored procedures, o PostgreSQL perde uma de suas principais vantagens.
- O MySQL, por outro lado, tem uma estrutura de armazenamento e indexação mais leve para cargas transacionais simples.
4. Custo e Escalabilidade
- O PostgreSQL exigiria mais recursos por banco, o que aumentaria os custos na nuvem.
- O MySQL escala melhor horizontalmente, permitindo adicionar novos clientes sem sobrecarregar os servidores.
Resumo da Decisão
Após considerar todos os fatores, o MySQL 8 se mostrou a melhor escolha para este cenário pelos seguintes motivos:
- Gerenciamento eficiente de múltiplos bancos (150 por servidor);
- Consome até 50% menos RAM e 40% menos CPU;
- Menor custo na infraestrutura geral;
- Melhor escalabilidade horizontal;
- Desempenho previsível para bases de 5GB.
Se, no futuro, as bases crescerem para além de 50GB cada, aí sim será o momento de reavaliar essa decisão e talvez considerar o PostgreSQL, mas não é o caso atual.
Conclusão: A Tecnologia Certa Depende do Contexto
A maior lição desse estudo não é sobre qual banco de dados é "melhor", mas sim sobre a importância de conhecer profundamente o ambiente onde a tecnologia será aplicada.
É fácil se deixar levar pelo hype ou pelas recomendações de outros profissionais, mas a verdade é que a melhor tecnologia é aquela que resolve o problema do cliente da forma mais eficiente e econômica possível.
No final do dia, a escolha técnica deve ser guiada por custo, eficiência, escalabilidade e aderência ao ambiente real de uso — e não apenas por benchmarks ou opiniões pessoais.
O segredo? Sempre analisar os números, testar, e tomar a decisão com base em dados concretos.
E o teste feito de quem consome mais levou em consideração a otimiação? Porque parece óbvio que compartilhar recursos economiza recursos, mas também a otimização já que tem que dividir o bolo. No fim pode ser que use até mais recursos porque pode ter que colcoar menos instâncias em situação real. Pode ser que até dê para colcoar mais instâncias, mas e o tempo de resposta será o mesmo sempre, ou ou usuários vão pagar um preço por isso, ainda que eles não reclamem?
Não sabemos as condições que os testes foram feitos. O PostgreSQL é amplamente personalizável para atingir certos objetivos, mas a maioria das pessoas não sabem fazer.
Muita gente reclama que o Windows usa muitos recursos, mas ele faz sim para otimizar o uso, consumir mais pode ser algo positivo.
É muito fácil e comum fazer um teste sintético e dar um resultado que não se reproduz quando usa real.
Se quer algo tão simples e melhor uso de recursos então use o SQLite. Este padrão de uso é para ele dar conta e permitir centenas de instâncias, ainda mais se criar uma fila de escrita que é onde ele pode ter algum gargalo. Ele é mais ACID que o MySQL. Se as bases forem de 50GB o SQLite ainda dá conta com sobras, só depende do volume de escritas efetivamente simultâneas, que é resolvido com um sistema de fila.
A maior lição é que a maioria das pessoas não conseguem fazer análises adequadas sobre tecnologias, inclusive as mais experientes vão errar muito, e se não for a diferença brutal e não for falsa, tanto faz oque ela vai usar na esmagadora maioria dos cenários. A escolha talvez seja melhor ao que lhe é familiar ou no que a pessoa está com mais vontade de usar. Números vivem mentido. Se você os torturam eles confessam o que você quiser.
Pode ser que este seja um super resumo, mas esta é uma avaliação extremamente superficial, quase semrpe você só terá uma boa tendo uma experiência enorme nos 2 de forma muito semelhante, ou implmentando de fato nos 2 do jeito correto e depois escolher qual usar e qual descartar.
Em escalas absurdas maiores de uso real tanto um quanto outro deram conta muito bem, e não se tem um cenário claro que um é pior do que outro. Tem até o caso famoso do Uber que trocou o PostgreSQL pelo MySQL (porque o volume deles é absurdamente alto, se fosse menor eles não trocariam), mostraram os motivos e a comunidade do PostgreSQL mostrou que foi só porque eles não souberam configurar direito.
A melhor eficiência do MySQL se dá com MyISAM, aí é onde pode ter um resultado melhor sifnificativo, em detrimento da confiabilidade e de alguns recursos.
Em toda minha experiência nunca vi um caso que foi realmente necessário trocar o banco de dados para ele dar conta do recado (se adotar o SQLite isso tem mais chances de ocorrer, se aumentar muito a escrita simultânea e não tiver um bom sistema de filas), vi casos de mudanças porque quem começou perdido vai tomar várias decisões perdidas. E a mudança custa extremamente cara, ou dará resultado pior porque muita gtente acredita que pode abstrair o DB sem pagar um preço alto de performance de um lado ou do outro. Se a pessoa acha que um dia pode precisar de outro banco, provavelmente ela está errada, mas se quer ter certeza deveria usar o que garante a melhor escala, todo mundo substima o custo da mudança.
Salvo raras exceções, ambos atenderão a demanda muito bem. A escolha pelo mais fácil pode ser o fator decisivo.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).
O QUE IMPORTA É COMO O BANCO TRATA SEUS DADOS
Primeiro, sim: contexto importa. Mas tem um detalhe que ninguém te contou: a forma como o banco guarda seus dados não é "feature", é O OFÍCIO. Enquanto você discute "escalabilidade" e "benchmarks", tem código por aí que trata seus bytes se fossem lixo.
Vamos direto ao ponto com TESTES DE FOGO:
- POSTGRESQL É UM PÂNICO (NO BOM SENSO):
Quando o PostgreSQL detecta um erro de I/O, ele ENTRA EM PÁNICO E DESLIGA. Parece radical? É. Mas é a postura correta: "Não vou brincar de roleta russa com seus dados, amigo."
Já o MySQL/MariaDB, no mesmo cenário, engasga, cospe um erro genérico, e deixa você descobrir que o tablespace do InnoDB sumiu — e quando você tenta recuperar, o banco te manda "innodb_force_recovery=1" e um "boa sorte".
Tradução: "Se vira, otário. Teus dados viraram pó, mas pelo menos o processo não crashou, né?"
- SQLITE: CÓDIGO ESCRITO POR MONGES BUDISTAS (COM DIREITO A MEDITAÇÃO SOBRE BYTES):
O código do SQLite é A BÍBLIA do tratamento de dados. Cada linha e comentário é uma aula, com checks de consistência, fsync até no diretório, e um respeito religioso pelo "disk I/O error".
Enquanto isso, o MySQL/MariaDB tem trechos de código que parecem macarrão instantâneo — cheios de "should we really be doing this???" nos comentários. Não é surpresa que, em testes com soft updates, o MariaDB perdeu tabelas inteiras após um simples desligamento.
- ZFS + POSTGRESQL = CASAMENTO PERFEITO (ENQUANTO MARIADB É O AMANTE QUE TE DEIXA NA MÃO):
Em testes com ZFS, o PostgreSQL trava em todas as operações ao detectar um disco offline — como deve ser. Já o MariaDB, mesmo com o pool suspenso, tentou escrever no vácuo e corrompeu o tablespace.
Tradução: PostgreSQL entende que "dados inconsistentes" são piores que "dados ausentes". MariaDB acha que "quem não arrisca, não petisca".
- O FILESYSTEM PODE SER HERÓI OU VILÃO (MAS O BANCO É O ÚLTIMO GUARDIÃO):
Em testes com ext4, PostgreSQL e SQLite mantiveram a integridade mesmo após desligamentos brutais. Já o MariaDB perdeu engines inteiras (InnoDB) e exigiu intervenção manual.
Ou seja: Se o banco não tem um código PARANOICO com escrita/leitura fica refém do filesystem.
RESUMÃO DA ÓPERA (PRA QUEM TEM PRESSA):
POSTGRESQL E SQLITE: Código escrito por engenheiros que já perderam noites chorando por dados perdidos. Cada fsync é uma oração, cada transação é um ritual.
MARIADB/MYSQL: Código escrito por devs que confiam em "ah, o filesystem resolve". Tudo é "trade-off", até a consistência dos seus dados.
ENTENDA: Escolher um banco só por "performance" ou "popularidade" é como comprar um carro sem cinto de segurança porque "é mais rápido". Pode ser rápido? Pode. Mas quando bater...
ENTÃO O MYSQL/MARIADB? QUANDO USAR?
Se você não liga pra dados (tipo: sistema de comentários de blog que ninguém lê).
Se você adora gastar madrugadas fazendo recover de tabelas (ótimo hobby, inclusive).
Se seu chefe fala "é open-source, mas a Oracle tá por trás? Confia!".
Conclusão
Não importa se é ERP, IoT ou app de TODO list: dados são a alma do negócio. Escolha bancos que tratem eles como ouro, não como lixo reciclável.
PostgreSQL e SQLite são BESTAS DE GUERRA nisso. O resto, é resto.
"Ah, mas é mais rápido..." — claro, até você descobrir que "rápido" inclui apagar dados sem perguntar.
Agora vai lá e testa na porrada. Tira o servidor da tomada no meio de um write e vê quem não corrompe seus dados. Spoiler: não vai ser o MySQL. 😈💥
Sei que não é o objetivo do seu post, mas poderia dar mais detalhes de manter cada cliente com seu banco de dados?
Eu pressuponho que atualmente a aplicação roda on premisses e cada cliente tem sua instância banco e agora nesse novo projeto será online.
Qual foi o racional para não criar o novo projeto com um tenantId por exemplo?
Em todo caso, bela análise. Escolher o banco pra um projeto nunca é fácil e nunca é uma decisão perfeita.
Reflexão bastante relevante! Vejo muito esse tipo de confusão nos ambientes corporativos. As pessoas se apaixonam por uma tecnologia e costumam se agarrar em determinadas qualidades para defender a adoção indiscriminada de uma tecnologia em detrimento de outra. Não avaliam o contexto em que ela será aplicada para então pesar quais critérios são mais relevantes a serem conaiderados. Gosto de Ambos os SGBD, e também tenho tendência a escolha do Postgres. Por experiência própria sei que ambos atenderiam o seu caso especifico (diversos bancos pequenos), mas certamente em um cenário de nuvem os custos de processamento e armazenamento devem receber maior peso na decisão e neste caso o ponto realmente vai para o MySQL. Parabéns pelo artigo e pela clareza de pensamento!
Por tudo que você disse, eu iria de SQLITE! Me parece o mais adequado! Mas apenas parece! Isso quem decidirá será você! :)
Excelente post, eu estava precisando desses comparativos e dos comentários, estive fora do mundo da TI por 6 anos, onde todo mundo usava MySQL/MariaDB e quando voltei tudo era Postgres.
PostgreSQL elimina muitos errors de banco de dados relacionais antigos - e por isso é mais que industry standard. To usando o Supabase e é ótimo!
Meus parabéns pelo texto, foi uma ótima análise.