Comment choisir MySQL ou PostgreSQL pour une application PHP

La décision entre MySQL et PostgreSQL ne devrait pas partir de celui qu’une personne de l’équipe connaît le mieux ni d’une requête spectaculaire vue dans une démonstration. Elle doit partir des opérations que l’application devra prendre en charge de manière fiable : enregistrer des commandes, réserver des disponibilités, recalculer des soldes, accepter des changements simultanés, générer des rapports ou intégrer des données externes.

Les deux moteurs sont des options matures pour une application PHP transactionnelle. La différence pertinente apparaît lorsque le modèle de données, le comportement en situation de concurrence, les garanties d’intégrité et la charge opérationnelle que l’organisation peut assumer sont précisés. Bien choisir n’élimine pas le travail de conception ; cela réduit les incompatibilités entre les règles métier et la plateforme de données.

Le point de départ : les opérations critiques

Avant de comparer les fonctionnalités, décrivez les flux qui ne peuvent ni perdre de données, ni dupliquer des effets, ni laisser des états incohérents. Une création d’utilisateur est différente de la confirmation d’un paiement, de la réservation d’une unité de stock ou de la consolidation d’une facture. Chaque opération a des exigences d’atomicité, d’ordre, de latence et de traçabilité.

Transformez les cas d’usage en une liste vérifiable. Pour chacun, notez quelles données il lit, quels enregistrements il écrit, quelle règle doit être respectée, combien d’utilisateurs ou de processus peuvent l’exécuter simultanément et ce qui se passe s’il est interrompu. Cet inventaire évite de décider selon une préférence technologique lorsque le problème est en réalité un modèle d’états mal défini.

• Opérations métier : créations, annulations, changements d’état, encaissements, remboursements et réservations.
• Processus asynchrones : importations, nouvelles tentatives, files d’attente, recalculs et notifications.
• Lectures opérationnelles : listes filtrées, fiches, permissions et recherches fréquentes.
• Lectures analytiques : agrégations, comparaisons temporelles, exportations et rapports.
• Intégrations : API, webhooks, systèmes comptables et sources de données externes.

Pour déterminer comment choisir MySQL ou PostgreSQL pour une application PHP, la question utile est : quelles erreurs le système doit-il empêcher, même si l’application présente une défaillance, si deux requêtes sont simultanées ou si un processus est relancé ?

Inventaire des données, règles et incertitudes

Modélisez les entités, les relations et les cycles de vie avant de sélectionner le moteur. Identifiez les clés primaires, les relations obligatoires, l’unicité, les montants, les dates, les états et les documents semi-structurés. Séparez également les données opérationnelles de celles qui servent uniquement à l’audit, à la recherche ou à l’analyse.

Les contraintes de base de données constituent une deuxième ligne de défense, et non un substitut aux validations PHP. L’application doit fournir des messages compréhensibles et valider les entrées ; la base de données doit renforcer les invariants qui ne peuvent pas être enfreints. Par exemple, une clé étrangère peut empêcher des références inexistantes, une contrainte d’unicité peut éviter de dupliquer un identifiant externe et une contrainte de vérification peut limiter les valeurs autorisées.

PostgreSQL est souvent particulièrement pratique lorsque le domaine nécessite des types riches, des vérifications expressives, des requêtes analytiques complexes ou une combinaison délibérée de structure relationnelle et de documents JSON. MySQL est également un choix solide pour de nombreux produits métier dotés de schémas relationnels, de transactions et de modèles de requêtes conventionnels. La décision ne doit pas transformer ces tendances en règles absolues : validez les requêtes et les règles réelles.

Des données flexibles sans perdre le contrat

Stocker des attributs variables dans JSON peut accélérer une première intégration, mais cela n’élimine pas la nécessité de définir quels champs existent, comment ils sont validés et comment ils sont interrogés. Si un attribut intervient dans les permissions, les prix, la disponibilité ou les rapports récurrents, il mérite généralement une structure explicite et des index adaptés. Les documents semi-structurés conviennent mieux à des données variables avec un contrat connu qu’à masquer un modèle que personne n’a décidé.

Évaluez l’écriture, les transactions et la concurrence

L’écriture concurrente est le domaine où de nombreuses décisions architecturales apparaissent. Il ne suffit pas de savoir que les deux moteurs prennent en charge les transactions : il faut tester quelles lignes sont mises à jour, combien de temps dure chaque transaction, quels index interviennent et comment les conflits sont gérés.

Une réservation de stock, par exemple, doit empêcher que deux requêtes confirment la dernière unité. La solution peut nécessiter une mise à jour conditionnelle, un verrouillage délibéré ou un contrôle de version optimiste, selon le flux. Il n’est pas judicieux d’ouvrir une transaction, d’appeler un service distant et de conserver des verrous en attendant la réponse. Limitez la transaction aux opérations de données nécessaires et concevez des compensations ou des nouvelles tentatives pour les défaillances externes.

• Mesurez les créations simultanées sur les mêmes entités ou ressources rares.
• Définissez quelles opérations peuvent être relancées sans dupliquer les effets au moyen de clés d’idempotence.
• Examinez les plans d’exécution et les index des mises à jour, et pas seulement ceux des listes.
• Enregistrez les délais d’attente, les verrous, les erreurs de transaction et les requêtes lentes.
• Testez avec des volumes et une concurrence représentatifs, et non seulement avec une base vide.

En PHP, utilisez une couche d’accès qui rende explicites les limites transactionnelles. PDO, un ORM ou un query builder peuvent faciliter le travail, mais ils ne décident pas eux-mêmes de l’isolation, de l’ordre de mise à jour ni de la stratégie de nouvelles tentatives. Une migration doit également refléter les contraintes, les index et les modifications de données associées, et ne pas se limiter à créer des colonnes.

Distinguez les lectures opérationnelles des rapports

Un écran opérationnel a généralement besoin de réponses prévisibles avec des filtres précis, un tri et une pagination. Un rapport peut parcourir de longues périodes, joindre de nombreuses entités et calculer des agrégats. Mélanger ces deux modèles sans conception entraîne qu’une exportation lourde concurrence l’activité quotidienne.

Commencez par les requêtes qui seront exécutées fréquemment et par celles qui peuvent dégrader le service. Définissez les filtres, la cardinalité attendue, l’ordre, la pagination et le besoin de cohérence. Créez des index pour des modèles observables, en vérifiant qu’ils ne pénalisent pas les écritures de manière inacceptable. Un index n’est pas une amélioration abstraite : il consomme de l’espace, ajoute du travail lors des insertions et des mises à jour, et doit justifier une requête précise.

PostgreSQL offre un large ensemble d’outils pour les requêtes complexes, les agrégations, les fonctions de fenêtre et l’extensibilité. MySQL peut résoudre efficacement de nombreuses requêtes relationnelles bien indexées et constitue une option raisonnable lorsque les modèles sont clairs. Si le besoin principal est la recherche textuelle avancée, l’analyse massive ou le reporting à grande échelle, évaluez également des composants spécialisés. Ne forcez pas la base transactionnelle à assumer une fonction différente sans définir la synchronisation, la cohérence et la récupération en cas de retards.

Opération : le critère qui ne doit pas être laissé pour la fin

Le meilleur choix technique échoue s’il ne peut pas être restauré, mis à jour ou diagnostiqué. Documentez qui administrera le moteur, comment les correctifs seront appliqués, quel environnement reproduit les incidents et quelle procédure permet de récupérer un service après une erreur humaine, une migration échouée ou une perte d’infrastructure.

Les sauvegardes ne sont pas suffisantes si les restaurations ne sont jamais testées. Établissez des objectifs de récupération adaptés à l’impact du produit et vérifiez périodiquement qu’une sauvegarde permet de reconstruire la base, d’appliquer les journaux nécessaires s’ils existent et de démarrer l’application avec des données cohérentes. Protégez les sauvegardes et les identifiants, limitez les privilèges, chiffrez les communications lorsque cela s’applique et conservez un audit des accès administratifs.

La supervision doit relier les symptômes techniques à leur impact : saturation des connexions, croissance du stockage, requêtes lentes, verrous, réplication en retard, erreurs d’authentification et durée des tâches de maintenance. L’équipe doit savoir interpréter ces signaux et disposer de procédures claires. Une technologie que personne ne peut exploiter avec confiance a un coût caché supérieur à une différence marginale de performance.

Alternatives qui augmentent le risque

Choisir un moteur pour une seule requête, pour une montée en charge future sans preuve ou parce qu’une autre entreprise l’utilise revient souvent à reporter la décision réelle. Il est également risqué d’installer MySQL et PostgreSQL dans le même produit sans frontière de responsabilité. Deux moteurs impliquent deux chaînes de sauvegardes, de mises à jour, d’alertes, de permissions, de migrations et de connaissances opérationnelles.

Utilisez les deux uniquement s’il existe une raison délimitée et durable : par exemple, une plateforme héritée qui doit coexister temporairement avec un nouveau service, ou une responsabilité de données séparée avec des interfaces claires. Définissez la propriété de chaque donnée, la source de vérité, la synchronisation, le traitement des défaillances et le plan de retrait. Répliquer des données entre les moteurs sans ces règles introduit des divergences difficiles à expliquer.

Matrice pratique pour prendre et revoir la décision

Évaluez chaque option à l’aide de preuves issues du système actuel et des risques proches, et non de préférences. Accordez un poids plus important aux flux dont la corruption ou l’indisponibilité aurait des conséquences significatives. La notation ne remplace pas la revue technique, mais elle oblige à rendre les hypothèses visibles.

1. Listez entre cinq et dix opérations critiques et leur niveau de concurrence.
2. Évaluez la complexité des requêtes, des rapports, des types de données et des besoins de recherche.
3. Indiquez les règles d’intégrité qui doivent être renforcées en dehors de l’application.
4. Évaluez les capacités réelles d’exploitation, de restauration, de supervision et de support interne.
5. Construisez un test bref avec les requêtes, les données et les conflits représentatifs.
6. Estimez le coût d’un changement ultérieur : migration, indisponibilité, validation et formation.
7. Documentez la décision, les limites acceptées et les signaux qui imposeraient de la revoir.

Le choix approprié est celui qui permet de maintenir les opérations critiques avec des règles claires, des performances vérifiables et une exploitation que l’équipe peut assurer.

MySQL ou PostgreSQL ne sont pas une identité architecturale. Ce sont des composants qui doivent s’intégrer au modèle métier, au code PHP, aux pratiques de livraison et à la responsabilité opérationnelle. Décider à partir de flux concrets permet de commencer sur une base raisonnée et de conserver des critères objectifs pour la faire évoluer.