Cos'è LTAP?

LTAP (Lake Transactional/Analytical Processing) è l'architettura con cui Databricks, a giugno 2026, ha proposto di servire le transazioni operative e l'analisi dagli stessi dati, invece che da due sistemi tenuti allineati da una pipeline. L'applicazione scrive su un database Postgres come farebbe con qualunque gestionale, e le stesse righe diventano leggibili dagli strumenti di analisi senza che nessuno le copi altrove. L'unificazione avviene nello storage: i dati del database vivono su storage a oggetti nel cloud e vengono riscritti in automatico nel formato a colonne che usano i motori analitici, cioè file Parquet esposti come tabelle Delta o Iceberg. I motori restano due, uno fatto per le tante scritture piccole e uno per le grandi letture aggregate, ma la copia dei dati è una e i permessi sono governati in un solo posto. La sigla richiama HTAP, l'idea più vecchia di far fare entrambe le cose allo stesso motore, ed è proprio qui che LTAP se ne distingue.

Leggi anche: OLAP vs OLTP · OLTP gestisce le transazioni operative (scritture veloci, dati normalizzati); OLAP alimenta l'analisi (letture aggregate, dati denormalizzati).

Il problema che vuole eliminare

La divisione descritta in OLAP vs OLTP ha un costo nascosto: i dati nascono nel database operativo e per arrivare all'analisi devono essere copiati, di solito con change data capture e un flusso ETL/ELT. Ogni copia è una pipeline da mantenere, un ritardo tra il fatto e il report, e un secondo posto in cui definire chi può vedere cosa. LTAP sposta l'unificazione nello strato di storage: il database transazionale (che Databricks chiama Lakebase, un Postgres serverless nato dall'acquisizione di Neon) salva su object storage, e la conversione dal formato a righe a quello a colonne avviene mentre i dati arrivano nel lake, non in un processo esterno.

La differenza con HTAP è di impostazione. Un motore HTAP prova a essere bravo in due mestieri opposti nello stesso processo, e il compromesso si paga in prestazioni o in isolamento tra i due carichi. LTAP rinuncia a quel motore unico: le transazioni restano su Postgres con le sue garanzie, l'analisi sui motori del lakehouse, e ciascuno scala per conto suo. In comune hanno solo i file, scritti in formati tabellari aperti.

Un esempio enterprise

Un distributore gestisce ordini e giacenze su un'applicazione Postgres e ogni notte copia le tabelle nel data warehouse per i cruscotti commerciali. Con un'architettura LTAP la copia notturna sparisce: il responsabile vendite interroga le giacenze della mattina, non quelle della sera prima, e le regole di accesso ai dati dei clienti si scrivono una volta sola invece che nel database e nel warehouse. Il team non mantiene più il job di sincronizzazione, che era il primo punto a rompersi a ogni modifica dello schema.

Perché conta per chi decide

LTAP è un nome dato da un fornitore alla propria architettura, non uno standard, e va valutato così. Tre domande prima di sceglierlo. Quanto è maturo: nella documentazione di luglio 2026 alcune parti, come l'interrogazione di Lakebase dal motore analitico in tempo reale, erano ancora in beta o in anteprima. Quanto è aggiornato il dato analitico sotto carico: tra il commit su Postgres e la sua disponibilità in colonne c'è un passaggio di conversione, e il ritardo reale va misurato sul proprio volume di dati. E quanto lega: Postgres e i formati sono aperti, ma il servizio che li converte e li governa esiste solo su Databricks. Chi ha già il lakehouse su quella piattaforma ha molto da guadagnare; chi parte da zero sta scegliendo prima di tutto un fornitore, e la comparazione tra i candidati è nella voce dedicata a confronto tra Databricks, Snowflake, BigQuery e Fabric.