Le problème que personne ne veut regarder en face
Une ligne vieille de cinq ans occupe exactement le même espace de stockage bloc, au même tarif, qu'une commande passée il y a trente secondes. PostgreSQL ne fait aucune différence entre les deux, et c'est bien normal : ce n'est pas son rôle. Mais pour les entreprises qui accumulent des téraoctets de logs, d'événements ou de données métier, cette absence de hiérarchisation a un coût bien réel.
C'est le point de départ d'un article de Shaun Thomas publié sur le blog officiel de PostgreSQL, "The Long Road to Bottomless Postgres". Son constat est simple : la majorité des moteurs de bases de données traitent toutes les données de la même manière, qu'elles soient consultées des milliers de fois par jour ou qu'elles dorment depuis des années dans une table d'archive. Résultat, on paie du stockage bloc premium pour des données qui pourraient très bien vivre sur de l'object storage à une fraction du prix.
Découpler le calcul du stockage : une idée qui fait son chemin
L'idée n'est pas nouvelle, mais elle gagne du terrain : pousser les données froides vers du stockage objet bon marché (type S3), garder les données chaudes sur du stockage local rapide, et permettre à une seule requête de parcourir les deux de façon transparente. Encore mieux, stocker ces données froides dans un format columnar ouvert, pensé pour l'analytique plutôt que pour la lecture ligne par ligne.
Cette vision a donné naissance à tout un écosystème d'extensions, de forks et de ré-architectures autour de PostgreSQL, chacune avec sa propre approche. Mais comme le souligne l'article source, aucune solution ne s'impose encore comme "la" référence définitive. Chaque approche demande une concession : un binaire forké à maintenir, un daemon supplémentaire à opérer, une copie dupliquée des données, ou parfois l'abandon pur et simple des écritures sur les données archivées.
Le partitionnement déclaratif comme première brique
La bonne nouvelle, c'est que PostgreSQL fournit déjà un outil natif pour amorcer cette stratégie : le partitionnement déclaratif. En découpant les tables en partitions bien définies (par date, par plage de valeurs, etc.), le planificateur de requêtes peut faire du pruning et ignorer purement et simplement les partitions non pertinentes pour une requête donnée.
À partir de là, rien n'empêche de pousser le raisonnement plus loin en exploitant les tablespaces pour fédérer physiquement les données "chaudes" et "froides" : les partitions récentes sur du SSD rapide et coûteux, les partitions anciennes sur un tablespace pointant vers un stockage moins onéreux. C'est une base solide, mais ce n'est qu'un point de départ : l'objectif final reste de pouvoir interroger l'ensemble du jeu de données, peu importe où il réside physiquement, sans complexité ajoutée côté application.
Pourquoi ce sujet compte particulièrement quand on prépare des données pour l'IA
Ce qui rend cette problématique d'autant plus pertinente aujourd'hui, c'est l'essor des usages autour de l'IA. Beaucoup d'équipes hésitent à purger leurs logs applicatifs, leurs traces d'événements ou leurs historiques métier, précisément parce que ces données pourraient un jour servir à entraîner ou affiner des modèles. Mais conserver indéfiniment des téraoctets de données « au cas où » sur du stockage bloc premium, ce n'est tout simplement pas tenable financièrement.
Un stockage hybride, où les données récentes restent rapidement accessibles pour les besoins opérationnels (OLTP) tandis que les données anciennes basculent automatiquement vers du stockage objet économique tout en restant interrogeables pour des besoins analytiques (OLAP), change la donne. On peut alors garder l'intégralité de l'historique, sans sacrifier le budget infrastructure, et constituer petit à petit un socle de données exploitable pour de futurs projets de machine learning ou de fine-tuning, sans avoir eu besoin d'anticiper précisément ce besoin au moment de la collecte.
C'est exactement la direction que prennent des projets comme pgEdge, mentionnés en filigrane dans l'article source, qui cherchent à unifier les workloads IA, analytiques et transactionnels sur une seule base PostgreSQL, avec des réductions de coûts de stockage annoncées jusqu'à 90%.
Ce qu'il faut retenir
La promesse d'un PostgreSQL "sans fond", capable d'absorber des volumes de données croissants sans faire exploser la facture de stockage, n'est pas encore une solution unique et standardisée. L'écosystème reste fragmenté entre forks, extensions et architectures concurrentes, chacune avec ses compromis. Mais les fondations existent déjà dans PostgreSQL natif : partitionnement déclaratif, tablespaces, et une planification réfléchie de la rétention des données.
Pour les équipes qui, comme beaucoup de nos clients chez MulerTech, doivent jongler entre besoins transactionnels immédiats et constitution d'un patrimoine de données pour l'analytique ou l'IA, c'est un sujet à suivre de près : la bonne stratégie de tiering peut transformer un poste de coût qui grimpe indéfiniment en un investissement maîtrisé sur le long terme.
Article source : "The Long Road to Bottomless Postgres" par Shaun Thomas, sur le blog PostgreSQL.
