Não é bem assim que você deve fazer a análise. A forma como você vai fazer pode definir mais o que é útil. E aspectos políticos provavelmente pesarão mais que os técnicos.
Só não pense em usar MongoDB. Até dá, mas ficará péssimo. um ERP praticamente exige um banco de dados relacional, nem passe perto de outros. quem usa um modelo de documento em caso assim vai abusar muito dele. Precisa muita ingenuidade para usar NoSQL em algo que claramente será todo de dados tabulares, com relacionamentos e com schema essencialmente fixo (a maioria dos bancos relacionais hoje permitem flexibilidade quando precisa).
Lembrando que hoje quase todos os relacionais possuem pelo menos 2, 3 ou mais modelos operando junto além do relacionam, entre documento, grafo, espacial, chave e valor, RDF, time series, vetor e até colunar, e todos permitem uma forma básica ou sofisticada de busca textual que pode servir para a maioria dos propósitos.
Você pode usar até o SQLite e provavelmente vai bem. Eu sei que muita gente acha que não, mas já usei, conheço várias pessoas que usaram e quem entende de banco de dados com profundidade sabe que dá. Desde que o volume de escrita concorrente nele não seja muito grande e tome alguns cuidados, pode ser até que precise criar uma fila. Ou seja, não é para qualquer um adotar isso. Você ficará mais tranquilo com o outro produto.
Quer algum produto de baixa popularidade? Geralmente a maioria não quer, então elimina dezenas ou centenas deles, por exemplo DB2, Informix e talvez até o Firebird que é o mais usado entre os pouco usados e o menos usado entre os mais usados. Nenhum deles é ruim, o problema é a baixa popularidade.
Depois precisamos ver sobre você aceitar pagar pelo produto ou não. Embora muitos produtos possuem uma versão com limitações (em geral cada base de dados pode ter só 10GB de tamanho e costuma não ter certas otimizações), se quiser ter liberdade para além disso sem pagar não pode escolher Oracle ou SQL Server. Provavelmente os dois SGDBs mais poderosos do mercado, com folga, sendo o primeiro o maior de todos. Obviamente também são os mais difíceis para obter o melhor resultado que só eles conseguem entregar. Se vai pagar e consegue se virar para arrancar o melhor deles, pode escolher um dos dois, estará muito bem servido para qualquer carga de trabalho. Eu acho que não é o caso, mas está aí.
Pois bem, sobrou apenas PostgreSQL e MySQL. Na verdade, hoje quando alguém fala de MySQL no fundo está falando de MariaDB. Quase ninguém usa o MySQL por escolha realmente, geralmente usa por legado ou porque não sabe que o MariaDB existe, que é o mesmo produto em quase tudo, é praticamente um fork. Cada vez mais haverá diferença entre eles, mas até mesmo a licença e o fornecedor ajuda escolher o MariaDB.
Se for escolhê-lo então precisa ver se vai usar o InnoDB ou outro mecanismo de armazenamento. Sinceramente, se não for usar o Aria (ou MyISAM no MySQL), não sei se ele tem tanta vantagem assim. O InnoDB de fato tem várias vantagens, mas também tem desvantagens, e se ele for o indicado para você eu acho que o PostgreSQL é melhor. Porque o InnoDB perde algumas facilidades e performance que o Aria te dá, mas não dá tudo o que o PostgreSQL te dá.
Pra falar a verdade vai fazer pouca diferença. Eu até acho o PostgreSQL mais robusto para aplicações grandes, mas está provado que o MySQL dá conta muito bem, provavelmente só no InnoDB. O jeito que fará a aplicação definirá o que é melhor. Um ERP poderoso pode se dar melhor com PostgreSQL, mas um mais simples terá vantagens com Aria.
No fim, para um produto simples o que definirá mesmo é qual você está mais familiarizado. Se você souber o que está fazendo qualquer um dá conta e saber usar melhor é que dará o melhor resultado. Se não souber nenhum e puder aprender bem, pode seguir o que eu falei. Se não souber nenhum e acha que não poderá aprender qualquer um deles bem, então vai de MariaDB/MySQL, de preferência com Aria/MyISAM que é mais fácil. Mas o produto vai sofrer nessa condição. Certamente esses DBMS criados pelo Monty Widenius são mais fáceis de usar por iniciantes.
Cuidado com a ideia de usar algo para aceitar vários DBs diferentes. No fim fica ruim para todos, ainda mais se a pessoa não souber muito bem o que está fazendo, e se adotar isso provavelmente não sabe. Fica pior que um pato (veja mais, também).
Em resumo, exceto o SQlite, que tem características únicas que os outros não conseguem, todos os outros relaciconam darão conta do recado, desde que você saiba usar bem, ou mesmo sem saber, dsde que o volume não seja gigantesco (as pessoas tendem a achar que seu sistema será usado por ordens de magnitude maiores do que efetivamente será, por isso o SQLite provavelmente dará conta também, e o MongoDB não será trágico em performance, mas ainda será em consistência).
Reforço a ideia que a forma como fará é que deveria definir qual é o mais adequado para você. Se não sabe como vai fazer, até um sorteio poder funcionar. Engenharia é ter domínio de todo o processo.
Minhas respostas sobr DB no SOpt: https://pt.stackoverflow.com/search?tab=votes&q=user%3a101%20%5bbanco-de-dados%5d&searchOn=3.
Faz sentido para você?
Espero ter ajudado.
(podia ter colocado um título mais significativo, se for editar poderia dizer que quer recomendação de banco de dados para ERP)
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).