Une optimisation silencieuse qui peut transformer vos performances de stockage
Il y a des changements dans une nouvelle version de PostgreSQL qui font les gros titres — nouvelles commandes SQL, fonctionnalités de réplication, améliorations du planificateur. Et puis il y a ceux qui travaillent en silence, sous la surface, et qui peuvent pourtant avoir un impact direct sur vos coûts d'infrastructure et la vitesse de vos requêtes. Le passage de pglz à LZ4 comme algorithme de compression par défaut dans Postgres 19 appartient clairement à cette seconde catégorie.
Pas une ligne de code applicatif à modifier. Pas de migration de schéma. Juste une performance améliorée, presque automatiquement.
Comment Postgres compresse vos données aujourd'hui
Pour comprendre ce qui change, il faut d'abord saisir comment Postgres gère la compression. Le moteur utilise un framework unifié qui couvre trois zones de stockage :
- Le heap (tables) : la compression est automatique et activée par défaut pour les types à longueur variable —
TEXT, VARCHAR, BYTEA, JSONB.
- TOAST (The Oversized-Attribute Storage Technique) : mécanisme qui entre en jeu quand une valeur dépasse environ 2 Ko. Elle est alors compressée et/ou déplacée dans une table TOAST annexe.
- Les index : la compression est opportuniste — elle ne se déclenche que quand une clé individuelle dépasse le seuil de taille, pas systématiquement.
L'algorithme historique derrière tout ça est pglz, développé spécifiquement pour Postgres. Il a rendu de bons et loyaux services depuis Postgres 7.0 en 2000, mais il accuse aujourd'hui son âge face aux algorithmes modernes.
Une brève histoire de la compression dans Postgres
La compression dans Postgres a une origine assez pragmatique : contourner la limite stricte de 8 Ko par ligne imposée dans les premières versions. Postgres 7.0 introduisait un type lztext utilisant pglz — une première approche, mais qui obligeait les développeurs à choisir explicitement un type compressé.
La vraie révolution est venue avec TOAST, introduit dans Postgres 7.1 : la compression et le stockage hors-ligne des grandes valeurs devenaient transparents et automatiques, sans que le développeur ait à s'en préoccuper. La limite de 8 Ko disparaissait dans les faits pour les types variables.
Depuis, pglz est resté l'algorithme par défaut. Postgres 14 a introduit le support de LZ4 comme option configurable, mais sans en faire le défaut. Postgres 19 franchit ce pas.
LZ4 vs pglz : ce que les chiffres disent
La différence entre les deux algorithmes tient à leur philosophie de conception :
pglz a été optimisé pour un bon taux de compression dans un contexte où le CPU était précieux et la RAM limitée. Il favorise la densité de compression au détriment de la vitesse.
LZ4 est conçu pour être extrêmement rapide, aussi bien en compression qu'en décompression, avec un taux de compression légèrement inférieur mais tout à fait honorable. Dans la pratique, sur des charges de travail typiques :
- La vitesse de décompression de LZ4 peut être 3 à 5 fois supérieure à celle de pglz.
- La vitesse de compression est encore plus radicalement meilleure.
- Le taux de compression est comparable, parfois légèrement en faveur de pglz sur certains types de données.
Pour une base de données, la décompression est l'opération la plus fréquente — chaque SELECT sur une colonne compressée la déclenche. C'est là que LZ4 brille vraiment.
Impact concret sur vos requêtes
Sur des colonnes TEXT ou JSONB volumineuses (logs applicatifs, payloads API, contenu éditorial), le gain peut être significatif :
- Réduction de la latence sur les
SELECT qui lisent de nombreuses lignes avec des valeurs TOAST.
- Meilleur débit en écriture lors d'insertions massives.
- Réduction de la pression CPU sur les serveurs très sollicités.
Le stockage brut sera dans certains cas légèrement plus élevé avec LZ4 qu'avec pglz, mais le delta est généralement négligeable et largement compensé par les gains en performance.
Ce que vous devez faire (ou ne pas faire)
La bonne nouvelle : pour la majorité des applications, vous n'avez rien à faire. Le changement de défaut dans Postgres 19 s'applique aux nouvelles données. Les données existantes conservent leur compression d'origine.
Quelques points à surveiller néanmoins :
Pour les nouvelles installations
Rien de spécial. Profitez du gain automatiquement.
Pour les migrations depuis une version antérieure
Les données déjà stockées avec pglz restent en pglz. Si vous souhaitez migrer vers LZ4, vous pouvez le faire colonne par colonne avec :
ALTER TABLE ma_table
ALTER COLUMN ma_colonne SET COMPRESSION lz4;
Un VACUUM FULL ou une réécriture de la table sera ensuite nécessaire pour que les données existantes soient recompressées.
Pour forcer un algorithme spécifique
Si votre charge de travail est atypique (fort ratio compression/vitesse requis, par exemple pour de l'archivage longue durée), vous pouvez continuer à utiliser pglz explicitement :
ALTER TABLE archives
ALTER COLUMN contenu SET COMPRESSION pglz;
Paramètre de configuration global
Il est également possible de définir l'algorithme par défaut au niveau de l'instance via default_toast_compression dans postgresql.conf :
default_toast_compression = lz4
Conclusion : la performance par défaut, sans effort
Le passage à LZ4 comme compression par défaut dans Postgres 19 est le genre de décision d'infrastructure qui fait la différence sur le long terme. Pas spectaculaire à annoncer, mais très concrète dans ses effets : des requêtes plus rapides sur les colonnes volumineuses, une meilleure utilisation du CPU, sans aucune modification applicative requise.
Pour les applications PHP/Symfony manipulant de gros volumes de JSONB (configurations, payloads d'événements, contenu multilingue), ou des champs TEXT longs (articles, logs, emails), l'impact peut être perceptible dès la mise à jour.
Une bonne raison de plus de planifier la migration vers Postgres 19 quand elle sera disponible en production.
Source originale : Christopher Winslett — Postgres 19 Compression: from pglz to LZ4, Crunchy Data Blog (juillet 2026).
