Databricks is adding LTAP (Lake Transactional/Analytical Processing) to its serverless Postgres service, Lakebase, in the coming weeks. The move promises to merge OLTP and OLAP workloads without ETL pipelines, extensions, or the performance trade-offs typical of HTAP. Instead of unifying back-end engines, LTAP unifies data formats by converting Postgres data to Parquet in real time.

The technology is built from Databricks’ two recent acquisitions. In May 2025, it bought Neon for roughly $1 billion, gaining a transactional layer on object storage. The October 2025 acquisition of Mooncake provided the key mechanism: on-the-fly transcoding from Postgres to Parquet. This works by tapping the low CPU usage of Neon’s storage components. Safekeepers replicate row-based records, while the pagekeeper asynchronously reconstructs pages. LTAP uses the spare CPU cycles on these services to transcode data to Parquet as it lands on object storage, with a claimed latency of about one minute. The pagekeeper also caches the original Postgres format, creating a mirror that Databricks frames as a unified, copy-free data format.

The result is a system that supports both transactional and analytical queries directly on the same data, eliminating the complexity of managing separate pipelines or dual-format storage.

Prenez Neon. Ajoutez-y Mooncake. Vous obtenez LTAP (Lake Transactional/Analytical Processing).

Databricks compte intégrer cette architecture au sein de son offre Lakebase (Postgres serverless) « dans les prochaines semaines ». La promesse : pouvoir mêler OLTP et OLAP sans pipelines ni extensions… et en évitant le compromis de performance qu’implique HTAP. Le moyen : unifier non pas les back-ends, mais les formats de données.

LTAP exploite le surplus CPU de Neon

Lakebase découle de l’acquisition de Neon. Databricks avait finalisé l’opération en mai 2025 pour environ 1 milliard de dollars. Elle lui a apporté une brique transactionnelle sur stockage objet.

Acquis en octobre 2025, Mooncake a procuré le substrat de LTAP : un mécanisme de conversion « à la volée » de Postgres à Parquet. Il exploite deux composants de la couche de stockage de Neon. D’un côté, les safekeepers, qui assurent la réplication des enregistrements générés à partir des lignes. De l’autre, le pagekeeper, qui reconstruit les pages de manière asynchrone.

L’architecture LTAP tire parti de la faible consommation CPU de ces services. Elle utilise les cycles disponibles pour effectuer le transcodage Postgres-Parquet au moment du dépôt sur le stockage objet (latence annoncée : 1 minute). Le pagekeeper fait office de cache conservant le format Postgres. On est donc sur une forme de mise en miroir qui permet à Databricks de revendiquer un format unifié, sans copie.

À consulter en complément :

Bases de données coud : l’abondance de l’offre devient un défi

IBM secoue l’édifice Db2 pour y intégrer l’IA agentique

Face aux bases de données vectorielles, pgvector atteint-il ses limites ?

Injection de prompt et injection SQL : même concept ?

Illustration générée par IA

The post Databricks joue l’alternative à HTAP pour unifier transactionnel et analytique appeared first on Silicon.fr.