PostgreSQL ou MySQL : la lecture simple peut tromper

Pour choisir entre PostgreSQL et MySQL, il faut partir des requêtes qui pèsent réellement sur l’application. Une comparaison par type de charge attribue un avantage possible à MySQL pour les lectures par clé primaire et les insertions soutenues, et à PostgreSQL pour les jointures complexes, JSONB et l’analytique. Ces préférences décrivent des mécanismes et des scénarios : la comparaison ne publie pas de débits mesurés dans une configuration commune.

Une recherche de ligne isolée peut ainsi orienter vers MySQL alors que les requêtes décisives de la même application orienteraient vers PostgreSQL. Le schéma, les index, le matériel et le nombre de clients simultanés peuvent modifier le résultat. Le temps nécessaire pour administrer la base ou migrer une application compte aussi dans le choix.

Lecture par clé : ce que mesure vraiment le test le plus simple

Dans InnoDB, le moteur de stockage courant de MySQL, l’index groupé contient les données des lignes : une recherche par clé primaire mène à la page qui porte la ligne. Ce chemin peut économiser un accès par rapport à une organisation où l’index et les lignes sont séparés. Il explique un avantage possible pour cette requête précise, sans fournir à lui seul une mesure de vitesse.

PostgreSQL conserve les lignes séparément de ses index. Une lecture peut passer de l’index à la table, mais un parcours couvert par l’index peut éviter cet accès lorsque les conditions de visibilité le permettent. Le résultat varie donc avec les colonnes demandées, la taille des lignes et la part des données présentes en mémoire. Un filtre sur une colonne secondaire raconte déjà une autre histoire : dans InnoDB aussi, retrouver la ligne depuis un index secondaire peut demander une recherche supplémentaire.

Écritures : distinguer insertion et mise à jour

Les mises à jour répétées laissent des versions de lignes à entretenir dans PostgreSQL et InnoDB.

Une charge d’insertions continues n’éprouve pas les mêmes mécanismes que des mises à jour répétées des mêmes lignes. Dans PostgreSQL, les anciennes versions des lignes doivent être nettoyées ; InnoDB conserve l’historique nécessaire aux transactions dans ses structures d’annulation. Selon la fréquence des modifications et la capacité de l’entretien courant à suivre, l’espace occupé et la latence peuvent évoluer différemment. Une courte série d’insertions dans une table neuve ne révèle pas cette évolution.

La comparaison exige des transactions de taille semblable, des garanties de durabilité équivalentes et les index dont chaque application aura réellement besoin. Il faut observer les écritures pendant que des lectures continuent, car un bon débit d’insertion isolé peut coexister avec une forte dégradation des requêtes concurrentes. Pour une application qui modifie surtout quelques lignes très sollicitées, reproduire cette concentration est plus instructif que répartir uniformément les modifications sur toute la table.

Jointures, JSON et analytique changent la décision

Un index GIN de PostgreSQL relie plusieurs champs JSONB, tandis qu’un index MySQL cible un chemin JSON défini.

Relier plusieurs tables, filtrer les lignes puis agréger les résultats sollicite le planificateur bien davantage qu’une recherche par clé. PostgreSQL peut choisir entre plusieurs stratégies de jointure et paralléliser certaines opérations ; MySQL dispose aussi d’optimisations pour ces requêtes. La qualité du plan dépend notamment de la répartition des valeurs et des statistiques disponibles. Une préférence architecturale ne garantit donc pas que toutes les jointures seront plus rapides sur un moteur donné.

Pour les documents, la question décisive est celle des chemins JSON interrogés. La documentation de PostgreSQL sur JSONB décrit les index GIN qui recherchent des clés ou des paires clé-valeur dans de nombreux documents. Un tel index offre de la souplesse quand les filtres changent, mais occupe de l’espace et doit être entretenu lors des écritures. Si les requêtes visent toujours un chemin connu, un index ciblé peut aussi rendre MySQL efficace ; la comparaison porte alors sur les filtres prévus et sur le coût des index retenus.

Pour l’analytique, il faut regarder les lignes parcourues, les agrégations et la concurrence avec les transactions ordinaires. Une requête de rapport exécutée seule sur des données déjà en mémoire peut se comporter autrement pendant les commandes et les mises à jour. Les performances d’une lecture ponctuelle ne permettent pas de déduire celles d’un tableau de bord qui regroupe un grand volume de données.

Une matrice qui rend les résultats comparables

Une comparaison reproductible associe chaque mesure à une requête, un schéma et un environnement définis. Les versions des moteurs, les types de colonnes, les index, le volume et la distribution des données, la mémoire, le stockage et les paramètres de durabilité doivent être consignés. Pour chaque scénario, les deux moteurs doivent rendre le même résultat métier, même si leurs index et leurs plans d’exécution diffèrent.

La matrice peut séparer les charges suivantes, puis faire varier le nombre de clients simultanés pour chacune :

Les lectures simples distinguent la recherche par clé primaire du filtre sur une autre colonne, avec la même quantité de données retournées.
Les écritures distinguent insertions, mises à jour et suppressions, seules puis mêlées aux lectures, sur une durée qui laisse apparaître l’entretien courant.
Les jointures conservent les mêmes relations, filtres et agrégations ; les plans d’exécution aident à comprendre un écart de temps.
Les requêtes JSON séparent les chemins connus à l’avance des recherches variables et incluent le coût de maintien des index.
Les requêtes analytiques mesurent les agrégations seules, puis en présence de la charge transactionnelle attendue.

Pour chaque ligne, le débit doit être accompagné des latences, notamment celles des requêtes les plus lentes, de l’utilisation des ressources et de l’espace occupé. La configuration des connexions et du cache mérite d’être identique ou explicitement justifiée : elle peut déplacer la limite observée avant que le traitement des requêtes ne soit en cause. La matrice montre ainsi quel résultat concerne la charge recherchée, au lieu de fabriquer un classement général à partir d’essais différents.

Exploitation et migration peuvent peser plus qu’un faible écart

Un choix de base engage aussi les sauvegardes et restaurations, la surveillance, la réplication, la disponibilité et les compétences de l’équipe. La FAQ du projet PostgreSQL précise qu’aucune entreprise ne possède le projet et que des bénévoles comme des sociétés y contribuent. Cette gouvernance peut compter pour une organisation qui évalue sa dépendance à un fournisseur, mais elle ne détermine pas le temps nécessaire à ses opérations quotidiennes.

MySQL Community Edition est téléchargeable sous licence GPL et comprend notamment des fonctions de réplication, des connecteurs et MySQL Workbench. La disponibilité de ces composants ne dispense pas de prévoir l’hébergement, les sauvegardes, la supervision et le support dont l’application a besoin. Ces dépenses et ce travail dépendent de l’architecture retenue autant que du logiciel.

Remplacer une base existante ajoute l’adaptation du SQL, des types, des pilotes, des procédures et des opérations de maintenance. Il faut également vérifier que les transactions rendent les mêmes résultats avant de comparer leurs temps d’exécution. Si la base en place satisfait déjà les requêtes qui comptent, un petit avantage observé sur une lecture par clé peut ne pas compenser ce chantier.