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:

1. 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é?"

2. 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.

3. 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".

4. 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. 😈💥

PostgreSQL elimina muitos errors de banco de dados relacionais antigos - e por isso é mais que industry standard. To usando o Supabase e é ótimo!

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.

Por tudo que você disse, eu iria de SQLITE!
Me parece o mais adequado!
Mas apenas parece! Isso quem decidirá será você! :)

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!

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.

Meus parabéns pelo texto, foi uma ótima análise.