LTAP : la réponse de Databricks aux limites des systèmes translytiques (HTAP)

L’architecture LTAP, une alternative au modèle HTAP

Le fait de combiner les traitements analytiques (OLAP) et transactionnels (OLTP) n’est pas nouveau. C’est tout l’intérêt supposé des systèmes HTAP (Hybrid Transactionnal Analytic Processing) ou comme Forrester les appelle, les bases de données translytiques.

Or, selon Databricks, ceux-là n’éliminent pas la nécessité de copier les données, les moteurs peuvent entrer en conflit et les formats de stockage sont souvent propriétaires.

Plutôt que de combiner les moteurs sous une même ombrelle, Databricks dit unifier la couche logicielle de stockage. Les données sont stockées au format Apache Parquet, sous l’enveloppe Delta ou Apache Iceberg.

En pure théorie, il semble possible de stocker des données dans un espace de stockage objet afin de les interroger avec des moteurs différents.

« Vous pouviez déjà effectuer des opérations OLTP auparavant. Mais vous ne pouviez pas utiliser Iceberg ou Delta comme base de données centrale derrière vos applications nécessitant une faible latence », nuance Ali Ghodsi, cofondateur et CEO de Databricks. « Cela aurait été trop lent. Aujourd’hui, c’est possible ».

Devant la presse, puisque Databricks n’attire plus seulement les médias les plus techniques, le dirigeant est resté vague quant à l’architecture permettant à l’éditeur de « régler un problème vieux de plus de quarante ans ».

Sur scène, Reynold Xin, cofondateur de Databricks et architecte en chef de l’éditeur, rappelle les fondamentaux des systèmes transactionnels et analytiques. Les premiers enregistrent les données en ligne, tandis que les seconds les conservent dans un format colonnaire. Pour passer de l’un à l’autre, il faut généralement maintenir des pipelines de Change Data Capture (CDC), souvent complexes à gérer. « En interne, nous les appelons Continuous Data Corruption », plaisante l’ingénieur.

Neon – et donc PostgreSQL – comme base d’un lac de données analytique et transactionnel

Pour éviter cet effort, l’idée est de convertir à la volée les lignes écrites par un SGBD dans un format colonnaire, Parquet.

Databricks ne s’appuie pas ici sur des pipelines CDC managés, mais sur l’architecture de Neon, une solution rachetée pour environ 1 milliard de dollars en mai 2025. L’éditeur éponyme a essentiellement fait de PostgreSQL une base de données serverless en découplant le stockage du calcul. La solution, connectée à Unity Catalog, est désormais nommée Lakebase.

« Le stockage de type objet à la base du Lakehouse présente, comme vous le savez, de nombreuses qualités. Il est peu coûteux et très facile à faire évoluer, mais il est également lent et manque de cohérence transactionnelle », explique Nikita Shamgunov, vice-président chez Databricks, ex- CEO et cofondateur de Neon, lors de la conférence. « Nous sommes donc en train de reconstruire le stockage avec Postgres pour le faire fonctionner sur le “lake”. Nous avons introduit deux services supplémentaires, l’un pour les lectures et l’autre pour les écritures », rappelle-t-il. « Pour les écritures et la cohérence transactionnelle, nous avons développé les Safekeepers. Ceux-ci implémentent un protocole de consensus appelé Paxos, ce qui permet d’obtenir des écritures à faible latence. Nous avons ensuite introduit les PageServers, qui fournissent les fonctions de pagination au moteur de calcul Postgres. Ils assurent des lectures à faible latence ». La startup avait déjà mis en place cette architecture avant son acquisition.

Les données sont toujours créées par Lakebase sous forme de lignes. Pour passer au format colonnaire, Databricks a exploité une particularité des services de stockage présenté plus haut. « Il s’est avéré que les Safekeepers et les PageServers, puisqu’ils ne font que des lectures et des écritures sur le disque global et le réseau, sont limités par les I/O », explique Reynold Xin. En revanche, ils sous-utilisent les CPU qui leur sont alloués. « Cela nous a donc donné l’occasion d’exploiter ces processeurs inactifs sur ces services de stockage pour effectuer un transcodage à ce moment précis, afin de convertir les données d’un format orienté lignes vers un format orienté colonnes ».

Cet effort n’augmenterait pas de manière drastique l’utilisation des ressources CPU. Mieux, le passage à un format colonnaire permet de bénéficier de son « meilleur taux de compression, souvent situé entre 10 pour 1 et 100 pour 1 », ajoute le cofondateur.

A priori, un tel système a besoin de conserver les données dans un format orienté lignes et un autre orienté colonnes. Ici, ce ne serait pas nécessaire.

« Sur la partie écriture, nous sommes capables de remplir le besoin opérationnel, de récupérer des milliards de lignes, et dans les phases idle du CPU de les générer en colonne », affirme Nicolas Maillard, vice-président responsable du field engineering dans la région SEMEA chez Databricks. « Sur la partie lecture c’est la même chose, nous avons en mémoire les données nécessaires pour les traitements temps réel et nous sommes capables de les hydrater dans le temps nécessaire. De remonter et de redescendre les informations ».

Depuis sa création, Neon a parié sur la mise en cache des inserts au niveau des lignes, les requêtes applicatives, etc., en mémoire vive et dans des SSD NVMe. En principe, les données en ligne résident temporairement dans le système de pagination et peuvent être interrogées depuis ce même endroit.

Des doutes concernant les performances du côté transactionnel

Les experts partagent l’avis de Databricks concernant les systèmes HTAP existants. Ils les considèrent comme peu convaincants. Ce sont pourtant les marques de fabrique des acteurs comme Oracle ou SAP. Mais certains doutent que ce système LTAP fasse beaucoup mieux.

« Ici, il est clair que le volet OLTP fera défaut », commente Vladimir Churyukin, expert base de données chez ServiceNow, sur LinkedIn. « […] Postgres traite couramment des requêtes avec une latence de quelques centaines de microsecondes », souligne-t-il. « Il est difficile de croire que cela soit réalisable avec le stockage Iceberg, sous quelque forme que ce soit. Cela pourrait être utilisable pour certaines charges de travail capables de tolérer une latence élevée ». Pour l’ingénieur, 100 millisecondes représentent une latence élevée dans le monde transactionnel.

D’autres voient LTAP comme un « mécanisme de synchronisation entre le Lakehouse et Lakebase ». Dans les faits, cette capacité existe déjà sous la forme des tables synchronisées, mais cela nécessite de posséder les données dans les deux formats évoqués plus haut.

Pour les applications analytiques, même en quasi-temps réel, l’approche LTAP semble toutefois idéale. Les entreprises devront vérifier les dires de Databricks dès la mise à disposition de l’architecture LTAP en préversion. Cela veut dire qu’il faut également faire évoluer à la fois Parquet et PostgreSQL, reconnaît Nicolas Maillard.

Lors de sa présentation, Reynold Xin a évoqué la donation prochaine d’une librairie open source de writer LTAP au projet PostgreSQL. Elle servira à stocker les données au format Parquet. L’analyse d’une telle proposition en dira davantage sur le fonctionnement du système mis en place par Databricks.

En tout cas, l’intention est bien de prendre une place importante face à des acteurs établis, que ce soit avec LakeBase ou avec le mécanisme LTAP. Et Ali Ghodsi de confirmer que des recettes pour migrer de solutions PostgreSQL et Oracle vers LakeBase sont déjà disponibles.

« Ça suscite beaucoup d’intérêt. Mais pour être honnête, ce qui m’enthousiasme le plus, c’est simplement de pouvoir prendre en charge toutes les nouvelles workloads, notamment celles liées à l’IA agentique », affirme le CEO.

Databricks aurait vu son ARR atteindre 6,9 milliards de dollars, soit une croissance de 80 % d’une année sur l’autre. L’offre Lakebase générerait un revenue run rate de 100 millions de dollars.

Précisons que l’éditeur a présenté une fonction de branching afin de copier à l’écriture des données exploitées par des environnements de développement et de tests. Les nouvelles données sont stockées séparément, mais les pointeurs vers les données sont partagés. L’on imagine qu’une telle fonction servira aux applications analytiques et pour propulser des agents IA. Cette capacité est évidemment inspirée des branches de Git. De plus, l’acteur a annoncé la disponibilité prochaine de reprise après sinistres intercloud. En mai, Oracle défendait son offre en mentionnant – entre autres – que LakeBase ne disposait pas de ce filet de sécurité.

« LakeBase peut s’avérer intéressant pour les charges de travail évolutives et axées sur les développeurs », écrit Ludivico Caldara, Senior Principal Product Manager chez Oracle. « Mais les architectes doivent vérifier la latence et s’assurer que les requêtes les plus lentes restent dans des limites acceptables dans des scénarios réalistes impliquant un volume important d’écritures, des basculements, des redémarrages et un cache froid avant de l’utiliser pour les systèmes transactionnels les plus exigeants, soumis à un SLA élevé ».