L'essentiel du travail pour opérer PostgreSQL en production n'est pas visible de l'extérieur. C'est le retard de réplication qu'on ne remarque jamais, le vacuum qui tourne au bon moment, et les index qui correspondent aux vraies requêtes.
La réplication est la première chose que nous mettons en place — non parce que nous attendons une panne du primaire, mais parce que nous attendons de vouloir une lecture replica récente pour l'analytique, les sauvegardes et le rollback test occasionnel. Une replica en streaming avec un petit lag est aussi la police d'assurance la moins chère contre un DELETE accidentel.
Le Point-in-Time Recovery doit être testé, pas supposé. Nous lançons un exercice trimestriel de restauration : prendre la dernière archive WAL, restaurer sur une instance vierge, pointer un smoke test dessus. Si l'exercice dépasse le SLA, le SLA est de la fiction.
Le vacuum est souvent la source de pics de latence mystérieux. Les réglages par défaut tiennent jusqu'au moment où ils ne tiennent plus. Surveiller `pg_stat_user_tables` et ajuster les seuils par table fait partie des changements opérationnels au meilleur ratio levier/effort.
Rien de tout cela n'est glamour. C'est précisément le but — une base de données en production doit être ennuyeuse, et l'ennui est le résultat d'un travail que personne ne voit.