L’article explique pourquoi il est crucial de tester régulièrement la restauration des sauvegardes PostgreSQL, illustré par l’expérience de l’auteur. Un pg_dump quotidien, même automatisé et stocké hors site, reste théorique tant qu’il n’a pas été restauré, car son intégrité et sa lisibilité ne sont pas garanties. L’auteur partage son échec initial lors d’un exercice de restauration, révélant des pièges inattendus, et souligne l’importance de mesurer le RTO (Recovery Time Objective) plutôt que de se contenter d’un RPO (Recovery Point Objective) théorique.

L’auteur propose une méthode simple pour automatiser ces tests, en utilisant un conteneur dédié qui génère des sauvegardes compressées et chiffrées, avec une rotation configurable. L’exemple concret de son blog montre comment intégrer cette pratique dans une infrastructure existante via Docker Compose, sans dépendre de scripts maison. L’objectif est de transformer une sauvegarde passive en un processus vérifiable et répétable, avec des métriques tangibles.

Enfin, l’article précise que cette approche convient aux projets modestes (blogs, side projects) et exclut les solutions avancées comme le PITR ou la réplication. L’auteur insiste sur le fait qu’un backup non testé est aussi inutile qu’un dump corrompu, et encourage à intégrer ces exercices dans les bonnes pratiques DevOps.

Ce billet explique comment optimiser les performances d’un blog Symfony utilisant Doctrine et PostgreSQL 16 en analysant les requêtes avec l’outil EXPLAIN. L’auteur détaille l’utilisation de EXPLAIN (ANALYZE, BUFFERS) pour examiner les plans d’exécution, identifier des problèmes comme le N+1 masqué par le cache, et vérifier l’efficacité des index via pg_stat_user_indexes. Sur les 47 index de la base, seuls 14 sont réellement utilisés, illustrant l’importance de cibler les optimisations.

L’article montre comment interpréter les plans d’exécution, comme un Index Scan pour une requête par slug ou un Seq Scan inefficace pour une jointure de catégorie. Il souligne que PostgreSQL privilégie la stratégie la moins coûteuse, même si un index existe, et met en lumière des fonctionnalités comme Memoize pour éviter des lectures redondantes. L’analyse révèle aussi des requêtes mal optimisées, comme une jointure forçant un parcours complet de table.

Enfin, le billet insiste sur la nécessité de combiner EXPLAIN et les outils de profilage Symfony pour corriger les requêtes problématiques avant de vérifier en production. L’exemple concret du flux RSS démontre comment PostgreSQL optimise automatiquement certaines opérations, tout en rappelant que chaque index doit justifier son existence par une utilisation réelle.