Comment passer à l'échelle une base PostgreSQL
AvancéAvant de partitionner ou de répliquer, on épuise les leviers les moins coûteux : PostgreSQL monte très haut sur une seule machine.
L'ordre logique#
- Requêtes et index :
pg_stat_statements,EXPLAIN, index adaptés. C'est là que se trouvent 90 % des gains. - Cache applicatif pour les lectures répétitives (Redis, cache HTTP), et pool de connexions.
- Matériel (scale up) : plus de RAM (le jeu de données actif doit tenir en cache), disques NVMe, plus de CPU.
- Répliques en lecture pour décharger les lectures et les rapports.
- Partitionnement des très grosses tables (rétention, requêtes par période).
- Sharding (Citus, découpage applicatif) : dernier recours, complexité maximale.
Ce que « scaler » n'est pas#
| Mythe | Réalité |
|---|---|
| « PostgreSQL ne tient pas la charge » | Des dizaines de milliers de transactions par seconde sur un serveur correctement dimensionné |
| « Il faut du NoSQL pour aller vite » | Un schéma et des index adaptés battent presque toujours un changement de technologie |
| « Plus de connexions = plus de débit » | Au-delà de quelques centaines de connexions actives, le débit baisse (voir pool) |
Cas pratique : avant de recruter une équipe pour migrer vers un système distribué, mesurez : quel est le jeu de données actif (le « working set »), le ratio lectures/écritures, et les 10 requêtes qui consomment le plus de temps total ? La réponse est rarement « il faut un autre moteur ».