Jusqu’à récemment, la séparation des bases de données transactionnelles et des systèmes analytiques était considérée comme une bonne pratique architecturale. Aujourd’hui, alors que les entreprises adoptent des agents IA qui lisent, analysent et exploitent en continu les données métier, les fournisseurs d’entrepôts de données et de bases de données estiment de plus en plus que cette séparation est devenue un frein. Quelques semaines seulement après la présentation par Databricks de son offre Lakehouse Transaction and Analytical Processing » (LTAP), basée sur Neon Postgres, qui vise à rapprocher le traitement des données transactionnelles (OLTP) et le traitement des données analytiques (OLAP), EntepriseDB (EDB) lui emboîte le pas dans son offre Postgres AI.

Si les deux fournisseurs répondent à la même pression, à savoir permettre aux agents IA des entreprises d’exploiter des données opérationnelles en temps réel sans attendre les pipelines et les duplications, EDB affirme que son approche part d’un principe fondamentalement différent. Selon Max Romanenko, directeur de l’ingénierie chez EDB, « Databricks construit à partir du lakehouse vers l’extérieur, en essayant d’intégrer des capacités transactionnelles via Lakebase », alors que « EDB construit à partir de la couche opérationnelle avec PostgreSQL, là où les entreprises exécutent déjà leurs charges de travail les plus critiques. »

Focus sur PostgreSQL et Iceberg

« Contrairement à l’approche LTAP de Databricks, centrée sur le « lakehouse », EDB conserve PostgreSQL comme source opérationnelle de référence et utilise Apache Iceberg comme couche de catalogue partagée reliant Postgres aux moteurs de calcul ClickHouse, WarehousePG et Spark », a expliqué Max Romanenko. « De cette manière, les données opérationnelles restent dans Postgres tandis que les données historiques et hiérarchisées sont stockées dans un stockage objet géré par Iceberg, de sorte que les moteurs analytiques peuvent interroger les mêmes données via un catalogue commun sans nécessiter de copies distinctes ni de pipelines ETL », a-t-il précisé.

Selon le dirigeant, cette distinction architecturale est importante pour EDB, car le fournisseur cible les entreprises qui souhaitent disposer de capacités IA et d’analyse sans transférer de données sensibles vers une plateforme gérée dans le cloud : « Pour EDB, l’essentiel a toujours été que les données reposent sur une infrastructure que le client possède et contrôle. »

Priorité à la souveraineté des données

La mise en avant du contrôle par EDB « trouvera un écho auprès des DSI qui accordent la priorité à la souveraineté, aux données réglementées et au déploiement hybride », a souligné Stephanie Walter, responsable du pôle IA chez HyperFrame Research. « Ils pourront ainsi exécuter l’IA et l’analyse plus près des données, sur une infrastructure contrôlée par leur entreprise, sans créer un écosystème de données propriétaire supplémentaire. » Pour Ashish Chaturvedi, responsable de la recherche exécutive chez HFS Research, l’approche d’EDB en matière d’analyse convergée offrira des coûts plus prévisibles que le modèle LTAP de Databricks aux DSI qui ont déjà du mal à gérer leurs budgets analytique et IA. « Le modèle de tarification par cœur d’EDB peut faciliter la prévision des coûts par rapport aux plateformes de données cloud basées sur la consommation, où les volumes de requêtes, les charges de travail liées à l’IA et les besoins en traitement des données peuvent entraîner des fluctuations de facturation », a fait valoir M. Chaturvedi.

« Mais des factures prévisibles ne sont pas nécessairement synonymes de factures moins élevées », a averti Igor Ikonnikov, consultant chez Info-Tech Research Group. « Les exigences matérielles pour le traitement opérationnel des données à haut débit sont plus élevées et relativement plus coûteuses par rapport au stockage « lakehouse » bon marché », a-t-il fait remarquer. L’architecture d’EDB pourrait également simplifier la gouvernance des données en réduisant le nombre de plateformes que les entreprises doivent gérer. « Étant donné que les charges de travail opérationnelles, analytiques et IA peuvent accéder aux données via une base commune PostgreSQL-Iceberg, les entreprises pourraient éviter de déployer et de gérer plusieurs référentiels de données spécialisés, et auraient ainsi moins de systèmes à licencier et à sécuriser », a déclaré Devin Pratt, directeur de recherche chez IDC.

Réduire la charge architecturale pour les équipes d’ingénierie

L’analyse convergente d’EDB pourrait aussi simplifier les opérations pour les développeurs et les équipes d’ingénierie des données. Son architecture réduit le nombre de systèmes que les développeurs doivent intégrer et maintenir, tout en éliminant une grande partie du travail de pipeline traditionnellement nécessaire pour transférer les données entre les systèmes transactionnels et analytiques, selon Walter. Et, comme l’a indiqué M. Pratt, « l’absence d’ETL signifie beaucoup moins d’infrastructure à mettre en place et à défaire, ce qui permet aux ingénieurs de consacrer leur temps à créer de la valeur. »

EDB et Databricks ne sont pas les seuls à se lancer dans l’analytique convergent pour prendre en charge les systèmes « agentiques » et d’autres applications nécessitant un accès immédiat aux données opérationnelles, au contexte historique et aux contrôles de gouvernance. Snowflake a élargi le support des charges de travail opérationnelles en adoptant des formats de tables ouverts, tandis que Microsoft a regroupé ses services transactionnels et analytiques au sein d’une architecture de données plus large via sa plateforme Fabric.

Vers une évolution des bases de données autonomes ?

L’analytique convergent ne représente qu’une partie de la mise à jour apportée par EDB à sa plateforme Postgres AI. L’entreprise a aussi rendu généralement disponible une fonctionnalité dite de « base de données agentique », conçue pour automatiser les tâches courantes d’administration des databases. « Le système surveille en permanence des centaines d’indicateurs opérationnels et de performances, détecte les anomalies, recommande des mesures correctives et, lorsque les politiques d’entreprise l’autorisent, peut appliquer automatiquement des correctifs », a indiqué la société.

« Ces agents automatisés peuvent aider les entreprises à optimiser et à régler leurs bases de données jusqu’à 10 fois plus rapidement », a ajouté EDB. Mais Mme Walter se dit sceptique. « Il s’agit davantage d’une évolution des concepts de bases de données autonomes que d’une catégorie entièrement nouvelle. Cela fait des années qu’Oracle et d’autres éditeurs de bases de données proposent des fonctionnalités de bases de données autonomes. » Selon elle, EDB se distingue en étendant ces capacités autonomes grâce à un raisonnement basé sur l’IA, à des corrections automatisées et à des contrôles de gouvernance qui permettent aux entreprises de déterminer le niveau d’autorité accordé au système.