ColdFront de pgEdge : la convergence des données chaudes et froides en PostgreSQL

ColdFront de pgEdge : la convergence des données chaudes et froides en PostgreSQL

Temps de lecture : 5 min

Points clés à retenir

  • Architecture innovante : ColdFront conserve PostgreSQL comme point d’accès unique tout en transférant automatiquement les données anciennes vers Iceberg, éliminant les silos entre OLTP et OLAP.
  • Réduction des coûts : Le stockage des données froides sur des solutions objet comme Iceberg permet des économies significatives, avec la possibilité de modifier ou supprimer des enregistrements archivés via une simple requête SQL.
  • Dépendance à DuckDB : L’utilisation partagée de DuckDB comme moteur d’analyse intégré entre ColdFront, pg_lake et Lakebase crée un risque de concentration, à surveiller par les DSI.

La donnée industrielle au cœur de la performance client

Depuis douze ans que j’observe le marché, une constante demeure : les entreprises industrielles peinent à concilier performances opérationnelles et maîtrise des coûts de stockage. Pendant des années, la réponse a été la séparation des systèmes OLTP et OLAP, avec des transferts de données complexes et coûteux. Mais avec l’essor des agents autonomes et des applications IA générant des volumes massifs de données opérationnelles, cette dualité devient intenable. Ce qui fait vraiment la différence aujourd’hui, c’est la capacité à supprimer ces silos tout en conservant une architecture unifiée.

Les grandes manœuvres ont commencé fin 2024 avec Snowflake et son pg_lake, suivies de Databricks (LTAP), puis d’EDB. Mais c’est pgEdge qui m’a particulièrement accroché avec sa solution ColdFront. En juillet 2026, cette approche mérite qu’on s’y attarde sérieusement.

Actifs connectés : une révolution industrielle en marche

ColdFront est une architecture native de PostgreSQL qui hiérarchise les données en deux niveaux : les données chaudes (récentes, sur stockage rapide) et les données froides (anciennes, sur stockage objet Apache Iceberg). L’idée est simple mais diablement efficace : transférer automatiquement les enregistrements les plus anciens vers Iceberg tout en maintenant PostgreSQL comme unique interface pour les applications. En pratique, cela signifie que les requêtes récentes s’exécutent directement sur PostgreSQL, tandis que les requêtes sur données anciennes sont traitées en toute transparence via DuckDB intégré. Pas besoin de pipelines ETL ni de modifications applicatives. C’est ce qu’a expliqué Ashish Chaturvedi, responsable de la recherche exécutive chez HFS Research : « ColdFront traite Iceberg uniquement comme une couche de stockage transparente derrière PostgreSQL. »

Cette approche diffère radicalement de celle de Databricks, qui exige un lakehouse propriétaire comme centre de gravité, ou de Snowflake, qui nécessite des distinctions entre tables PostgreSQL et tables analytiques. Pour les secteurs réglementés comme la finance ou la santé, c’est un atout majeur.

Supprimer des lignes archivées avec une seule requête SQL

Ce qui fait vraiment la différence technique, c’est la capacité de modifier des données anciennes stockées dans Iceberg sans opération complexe. Dans la plupart des architectures concurrentes, les données froides sont en lecture seule. Une simple demande de suppression RGPD exige alors une restauration, une suppression et un réarchivage – une demi-journée de travail. Avec ColdFront, vous pouvez mettre à jour ou supprimer des lignes archivées via une seule instruction SQL. Comme l’a souligné Amit Chandak, directeur de l’analytique chez Kanerika : « Les entreprises ont besoin de pouvoir corriger ou supprimer des enregistrements même après leur transfert vers un stockage moins coûteux, ce que d’autres approches compliquent. » Soyons clairs : c’est un gain de productivité colossal.

Selon Phillip Merrick, cofondateur de pgEdge, cette capacité qualifiée de « niveau froid inscriptible » permet aux applications de conserver le même langage SQL sans modification. Pour les entreprises gérant d’importants volumes de données issues d’agents IA, le retour sur investissement est immédiat : coûts de stockage réduits et conformité simplifiée.

Une dépendance à DuckDB à considérer

Malgré ces avantages, un point mérite toute votre attention : la dépendance croissante à DuckDB. ColdFront l’utilise pour exécuter des requêtes sur Iceberg, tout comme pg_lake et Lakebase de Databricks. Comme le souligne Igor Ikonnikov, consultant senior chez Info-Tech Research Group : « DuckDB devient rapidement le moteur d’analyse intégré de facto. Mais si DuckDB est confronté à des changements de licence, des failles de sécurité ou des goulots d’étranglement, l’impact se répercutera sur plusieurs produits. » Un risque de concentration à ne pas négliger.

Mon conseil : si vous évaluez ces architectures, commencez par standardiser Apache Iceberg, car les quatre solutions le supportent comme format de table ouvert. Michael Leone, analyste chez Moor Insights & Strategy, recommande cette approche pour conserver une flexibilité ultérieure. Mais attention, la gouvernance du catalogue Iceberg reste un défi entre les différents fournisseurs, surtout quand des agents de multiples systèmes doivent interroger les mêmes tables.

En pratique, ColdFront se distingue par son centre de gravité clair : PostgreSQL. Si votre écosystème repose déjà sur cette base de données, c’est une solution naturelle pour réduire les coûts sans sacrifier la performance. Sinon, pesez bien les compromis en fonction de votre infrastructure existante et de vos besoins en conformité.