Pendant des années, les entreprises ont maintenu des systèmes distincts pour le traitement des données transactionnelles (online transaction processing, OLTP) et analytiques (online analytical processing, OLAP), même si cela impliquait de transférer les données d’un système à l’autre. Cependant, l’essor des agents autonomes et des applications IA, nécessitant un accès immédiat aux données tout en générant eux-mêmes des volumes importants de données opérationnelles, a mis en évidence le coût et la complexité liés à la maintenance de ces systèmes séparés. La réponse du secteur n’a pas tardé : pour supprimer ces silos de données, les fournisseurs d’entrepôts de données et de bases de données ont proposé plusieurs approches concurrentes. A la fin de l’année dernière, Snowflake a lancé pg_lake, et il y a quelques jours, Databricks a dévoilé LTAP et EDB qui pousse la convergence des deux systèmes pour les besoins des agents IA. Toutes ces solutions proposent des modèles différents pour rapprocher les charges de travail transactionnelles, analytiques et IA. C’est désormais au tour de pgEdge, fournisseur d'une base de données PostgreSQL distribuée, qui a présenté récemment une version bêta de ColdFront, une architecture de hiérarchisation des données chaudes et froides natives de PostgreSQL. Avec pour capacité de transférer automatiquement les données les plus anciennes vers le stockage objet Apache Iceberg, tout en conservant PostgreSQL comme seule base de données avec laquelle les applications doivent interagir.

Dans l’architecture de ColdFront, les termes chaud et froid désignent respectivement les données récentes et les données plus anciennes. Le choix de conserver PostgreSQL comme interface principale distingue ColdFront des autres architectures émergentes. Selon les analystes, la différence réside dans la localisation du centre de gravité des données. Le modèle LTAP de Databricks maintient par exemple les applications opérationnelles connectées à un lakehouse où sont effectués les analyses et les traitements d’IA. Tandis qu'EDB conserve PostgreSQL comme source opérationnelle de référence tout en exposant les données via Iceberg pour les moteurs analytiques. « Quant au pg_lake de Snowflake, il écrit directement les données PostgreSQL dans Iceberg afin que PostgreSQL et Snowflake puissent tous deux interroger les mêmes données », a expliqué Ashish Chaturvedi, responsable de la recherche exécutive chez HFS Research. « ColdFront, en revanche, traite Iceberg uniquement comme une couche de stockage transparente derrière PostgreSQL, déplaçant automatiquement les données plus anciennes hors de la base de données tout en conservant les applications sur les mêmes tables et le même langage SQL », a précisé Ashish Chaturvedi.

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

Phillip Merrick, cofondateur de pgEdge, explique que cette différence fait que les requêtes portant sur des données récentes continuent de s’exécuter sur PostgreSQL, tandis que celles concernant des enregistrements plus anciens sont exécutées de manière transparente à l’aide du moteur analytique intégré de DuckDB, de sorte que les applications peuvent utiliser le même langage SQL sans avoir à mettre en place des pipelines ETL, des chemins de requête distincts ou des modifications au niveau des applications. Cela signifie également que les anciens enregistrements stockés dans Iceberg peuvent être mis à jour via PostgreSQL sans nécessiter de modifications des applications, rendant possible ce que Philip Merrick a qualifié de « niveau froid inscriptible ».

Celui-ci pourrait séduire les sociétés cherchant à concilier la résidence des données, la souveraineté, la conformité réglementaire et les exigences opérationnelles croissantes de l’ère agentique. « Alors que les entreprises conservent des volumes croissants de données opérationnelles historiques générées par des applications IA à des fins d’audit et de conformité réglementaire, elles ont de plus en plus besoin de pouvoir corriger, supprimer ou modifier des enregistrements, pour se conformer par exemple aux lois sur la protection des données et la vie privée, même après leur transfert vers un stockage moins coûteux, ce que d’autres approches concurrentes compliquent », a souligné Amit Chandak, directeur de l'analytique au sein du cabinet de conseil en IT Kanerika. Selon Ashish Chaturvedi, ColdFront peut simplifier ces processus. « Dans la plupart des systèmes à plusieurs niveaux, les données froides sont en lecture seule, si bien qu’une demande de suppression au titre du RGPD sur des données archivées implique une procédure de restauration, de suppression puis de réarchivage, ce qui représente une demi-journée de travail. L’architecture de ColdFront permettrait de mettre à jour et de supprimer des lignes archivées à l’aide d’une seule instruction SQL », a-t-il ajouté.

Ces architectures concurrentes impliquent toutefois des compromis différents : « Databricks demande aux entreprises d’adopter un lakehouse propriétaire comme centre de gravité opérationnel, Snowflake exige que les applications fassent la distinction entre les tables PostgreSQL et les tables analytiques alors qu’EDB continue d’exiger que les données archivées soient réintégrées dans une instance PostgreSQL active avant de pouvoir être modifiées », a-t-il détaillé. Selon Igor Ikonnikov, consultant senior chez Info-Tech Research Group, « ces compromis revêtent une importance particulière pour les secteurs réglementés ». Celui-ci a indiqué que les entreprises des services financiers, de la santé et du secteur public souhaitent de plus en plus conserver leurs données opérationnelles sensibles sur une infrastructure contrôlée par le client, tout en ayant la possibilité de modifier les enregistrements historiques afin de se conformer à des obligations réglementaires en constante évolution.

Une dépendance à DuckDB à considérer

Malgré leurs différences architecturales, tous ces fournisseurs masquent une convergence émergente à un autre niveau de la pile qui devrait susciter l’attention des DSI, à savoir une dépendance croissante à DuckDB. « ColdFront utilise DuckDB pour exécuter des requêtes sur les données stockées dans Iceberg. Le pg lake de Snowflake achemine les requêtes Iceberg via pgduck_server, et Lakebase de Databricks s’appuie également en interne sur DuckDB pour certaines parties de son traitement analytique. « En conséquence, DuckDB est en train de devenir rapidement le moteur d’analyse intégré de facto pour cette nouvelle génération d’architectures PostgreSQL-Iceberg », a fait remarquer Igor Ikonnikov, selon lequel cette dépendance croissante engendrerait un risque de concentration. « Si DuckDB était confronté à des changements de licence, à des failles de sécurité, à des goulots d’étranglement en termes de performances ou à des problèmes de gouvernance, l’impact se répercuterait simultanément sur plusieurs produits », a-t-il mis en garde. Par conséquent, les DSI doivent bien comprendre le niveau de maturité et la feuille de route des composants partagés dont ces architectures dépendent de plus en plus.

Cependant, cette similitude au niveau des composants partagés ne facilitera pas pour autant l’évaluation de ces architectures concurrentes par les DSI. « La plupart des entreprises disposent déjà d’architectures de données bien établies », a rappelé Michael Leone, analyste principal chez Moor Insights & Strategy, qui estime que les DSI devraient évaluer ces plateformes en fonction de l’emplacement actuel de leurs données, de leurs développeurs et de leurs flux de travail opérationnels, plutôt que de partir du principe qu’une seule architecture convient à tous les environnements. Pour les entreprises qui sont encore en train de définir leur stratégie de données à long terme, Michael Leone recommande de commencer par standardiser Iceberg, car les quatre architectures prennent en charge le format de table ouvert et les entreprises conserveront ainsi la flexibilité nécessaire pour remplacer ultérieurement la base de données frontale ou la plateforme analytique sans avoir à migrer les données sous-jacentes. « Même cette portabilité a toutefois ses limites », a néanmoins averti Igor Ikonnikov. « Le problème réside dans la gouvernance du catalogue Iceberg. Les quatre approches écrivent dans Iceberg, mais elles utilisent des catalogues différents et leur interopérabilité entre les différents fournisseurs reste un problème non résolu. Lorsque des agents provenant de plusieurs systèmes doivent interroger les mêmes tables Iceberg, la fédération des catalogues devient un véritable défi opérationnel. »