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