Quels sont vos SGBD gratuits préférés en 2022 ? Et pourquoi ?

Je n'utilise pas toujours la même BD en fonction du projet, donc j'ai eu l'occasion d'utiliser la plupart des serveurs libres.
J'ai eu parfois certains projets tournant en PostgreSQL et d'autres en MariaDB, simplement parce que chacun avait une librairie exclusive que je n'avais pas le temps de réécrire/remplacer juste pour changer de serveur. Mais on a toujours des fan boys qui envoient un commentaire juste pour demander pourquoi je ne supporte pas aussi le concurrent, même si je l'avais déjà expliqué sur le site!

Autrefois j'aurais préféré MySQL mais depuis le rachat par Oracle, elle a perdu de sa superbe et même son fork mariaDB n'a pas repris les parts de marché dévolues à PostgreSQL.
Reste que MySQL peut fonctionner en mode non-transactionnel, ça peut être source de meilleures performances dans certains cas (par exemple, pour héberger un blog qui est lu très souvent mais rédigé toujours par la même personne donc pas d'écritures concurrentes). Dommage que les autres ne le proposent pas, mais après tout c'est du libre, si on veut une fonction on n'a qu'à la faire soi-même!

SQLite, c'est ce que j'utilise quand je veux faire de l'embarqué, mais je préfèrerais qu'il y ait quand même des types. Au passage je peux aussi citer quelques serveurs SQL qui ont été oubliés ici: Apache Derby, ou Hypersonic SQL. Chaque fois que je veux faire de l'embarqué en Java, je les préfère à SQLite parce qu'ils supportent vraiment des types. Mais c'est uniquement pour Java. Alors pour les projets non-java, je vais regarder ce que Firebird propose, puisqu'il est également adapté à l'embarqué.

Apparemment MongoDB a un peu trop joué avec les changements de licence, ça a pu en décourager certains.
Heureusement NoSQL ne se limite pas à MongoDB.

Le NoSQL a surtout suscité une levée de boucliers de la part des DBA qui ne voulaient surtout pas avoir à faire autre chose que du SQL. Ils nous avaient déjà fait le coup avec ODMG: ils comparaient une base Oracle hyper-optimisée avec un équivalent qu'ils avaient écrit au lance-pierres avec le concurrent, et ensuite ils se servaient du benchmark biaisé pour dire que SQL était plus performant.

Plus simple, ça dépend pour qui. Si c'est pour intégrer des outils déjà écrits, certes.
Mais en tant que développeur et non DBA, pour moi l'absence d'un vrai modèle objet dans SQL (sauf en partie dans PostgreSQL avec l'héritage de tables) est une catastrophe: ça a entraîné la création de plein d'ORM (des librairies qui tentent de simuler le modèle objet avec des tables SQL) ce qui paradoxalement nuit à SQL parce qu'avec un ORM tu n'écris plus toi-même tes requêtes, elles sont générées par un moteur générique qui sous prétexte de supporter des dizaines de serveurs SQL distincts, génère des requêtes tout sauf optimisées... et ensuite on se fait engueuler par le DBA.

Pour une fois le sondage portait sur le gratuit, pas le libre. On insiste souvent sur la différence entre les deux, et pour une fois il n'y avait pas d'erreur, le sondage cite les principaux produits gratuits, sinon ils n'auraient pas cité SQL server ou Oracle XE. Donc tu aurais pu voter pour eux.

ça dépend pour quoi. En tant que développeur, j'utilise très souvent une base PostgreSQL en développement tout en sachant que la version de prod, sur laquelle je n'aurai jamais à aller, sera en Oracle.
Pourquoi pas directement en Oracle? Parce que même en version XE, Oracle reste plus compliqué à installer que Postgres, et moi je suis développeur pas DBA, donc la BD est un composant de mes développements, pas le point principal.
Et pourquoi PostgreSQL plutôt qu'un autre produit libre? Pour en revenir à ta citation, de tous les serveurs libres ça reste celui dont la syntaxe SQL est la plus proche de celle d'Oracle, donc une partie raisonnable du code (mais pas la totalité on est d'accord) pourra fonctionner sur les deux serveurs, ce qui ne serait pas le cas avec MySQL/MariaDB ou Firebird.
Bien sûr certains vont me parler de performances. Mais moi je vous parle d'un environnement de développement, donc une base qui va de toute façon contenir une très petite quantité de données. Du coup dans cet environnement aucun problème de performances. S'il y a des optimisations à faire, on les verra mieux dans un environnement de test.
En termes de fonctionnalités, PostgreSQL reste le meilleur compromis quand on ne peut pas utiliser Oracle ou SQL Server, qu'on ne veut pas investir et qu'on n'a pas de souci de performances (en développement par exemple). Pour les performances en production c'est un autre débat dont je ne parle pas ici et maintenant.