Cinque anni fa Databricks ha coniato il termine “data Lakehouse” per descrivere un nuovo tipo di architettura dati che combina un data Lake con un data warehouse. Questo termine e l’architettura dei dati sono ora ampiamente utilizzati nel settore dei dati per i carichi di lavoro di analisi.
Databricks sta ancora una volta cercando di creare una nuova categoria con il suo servizio Lakebase, che è generalmente disponibile oggi. Mentre la struttura Data Lakehouse si occupa dei database OLAP (elaborazione analitica online), Lakebase si occupa esclusivamente di OLTP (elaborazione delle transazioni online) e dei database operativi. Il servizio Lakebase è in sviluppo da giugno 2025 e si basa sulla tecnologia acquisita tramite l’acquisizione di Databricks. Fornitore di database PostgreSQL Neon. È stato ulteriormente sviluppato nell’ottobre 2025. Acquisto di Mooncake, Ha apportato funzionalità per aiutare a collegare PostgreSQL ai formati di dati Lakehouse.
Lakebase è un database operativo serverless che rappresenta un ripensamento fondamentale del funzionamento dei database nell’era degli agenti IA autonomi. I primi ad adottarli, tra cui easyJet, Hafnia e Warner Music Group, stanno riducendo i tempi di consegna delle applicazioni dal 75% al 95%, ma l’innovazione architetturale più profonda posiziona i database come infrastrutture temporanee e self-service che gli agenti AI possono fornire e gestire senza intervento umano.
Questo non è solo un altro servizio Postgres gestito. Lakebase tratta i database operativi come sistemi informatici leggeri e usa e getta in esecuzione su un archivio data lake anziché come sistemi monolitici che richiedono un’attenta pianificazione della capacità e la supervisione dell’amministratore del database (DBA).
"Infatti, affinché la tendenza al jitter coding possa decollare, è necessario che gli sviluppatori credano di poter creare nuove applicazioni molto rapidamente, ma è anche necessario che il team IT centrale, o DBA, si senta a proprio agio con lo tsunami di applicazioni e database." Il co-fondatore di Databricks, Reynold Xin, ha detto a VentureBeat. "I database classici non possono scalare di conseguenza perché non possono permettersi di inserire un DBA per database e applicazione."
Consegna più rapida del 92%: da due mesi a cinque giorni
I dati di produzione mostrano l’impatto immediato oltre la visione della consegna del veicolo. Utilizzando Lakebase come motore di transazione per il proprio portale operativo interno, Hafnia ha ridotto i tempi di consegna delle applicazioni pronte per la produzione da due mesi a cinque giorni, ovvero del 92%. L’azienda di autotrasporti è andata oltre i report BI statici verso applicazioni aziendali in tempo reale per flussi di lavoro commerciali, finanziari e di flotte.
EasyJet ha consolidato oltre 100 repository Git in soli due repository, riducendo i cicli di sviluppo da nove mesi a quattro mesi (una riduzione del 56%) e creando un centro di gestione delle entrate basato sul web su Lakebase, sostituendo un’applicazione desktop vecchia di dieci anni e uno dei più grandi ambienti SQL Server legacy d’Europa.
Warner Music Group utilizza la base unificata per trasferire le informazioni direttamente nei sistemi di produzione, mentre Quantum Capital Group la utilizza per mantenere dati coerenti e gestiti per identificare e valutare gli investimenti nel petrolio e nel gas; eliminando così la duplicazione dei dati, che in precedenza costringeva i team a conservare più copie in formati diversi.
L’accelerazione deriva dall’eliminazione di due principali colli di bottiglia: la clonazione del database per gli ambienti di test e la manutenzione della pipeline ETL per la sincronizzazione dei dati operativi e analitici.
Architettura tecnica: perché non è gestito solo Postgres?
I database tradizionali combinano archiviazione ed elaborazione; Le organizzazioni forniscono un’istanza di database con spazio di archiviazione collegato e scalabilità aggiungendo più istanze o spazio di archiviazione. AWS Aurora ha innovato separando questi livelli utilizzando lo storage privato, ma lo storage è rimasto bloccato all’interno dell’ecosistema AWS e non è stato possibile accedervi in modo indipendente per l’analisi.
Lakebase porta la separazione tra storage ed elaborazione alla sua logica conclusione collocando lo storage direttamente nella Data Lakehouse. Il livello di calcolo esegue essenzialmente PostgreSQL, mantenendo la piena compatibilità con l’ecosistema Postgres, ma ogni scrittura va allo storage Lakehouse in formati che Spark, Databricks SQL e altri motori di analisi possono eseguire query al volo senza ETL.
"L’intuizione tecnica unica era che i data Lake separavano lo storage dall’elaborazione, il che era fantastico, ma dobbiamo incorporare funzionalità di gestione dei dati come la governance e la gestione delle transazioni nel data Lake." Xin ha spiegato. "In realtà non siamo così diversi dal concetto di casa sul lago, ma ci stiamo basando su per creare un’elaborazione leggera e ad hoc per i database OLTP."
Databricks ha costruito Lakebase con la tecnologia derivata dall’acquisizione di Neon. Ma Xin ha sottolineato che Databricks ha creato qualcosa di fondamentalmente diverso espandendo in modo significativo le capacità originali di Neon.
"Non avevano esperienza aziendale e non disponevano della scalabilità del cloud." Xin ha detto. "Abbiamo combinato l’idea architettonica unica del team Neon con la robustezza dell’infrastruttura Databricks. Ora abbiamo creato una piattaforma super scalabile."
Da centinaia di database a milioni di database creati per l’intelligenza artificiale delle agenzie
Xin ha delineato una visione legata direttamente all’economia degli strumenti di codifica dell’intelligenza artificiale, spiegando perché il framework Lakebase è importante al di là dei casi d’uso attuali. Man mano che i costi di sviluppo diminuiscono, le aziende passeranno dall’acquisto di centinaia di applicazioni SaaS alla creazione di milioni di applicazioni interne personalizzate.
"Man mano che il costo dello sviluppo del software diminuisce, come vediamo oggi grazie agli strumenti di codifica dell’intelligenza artificiale, negli ultimi 10-15 anni ci sarà uno spostamento dalla proliferazione del SaaS alla proliferazione dello sviluppo di applicazioni interne." Xin ha detto. "Forse invece di sviluppare centinaia di applicazioni, nel tempo svilupperanno milioni di applicazioni personalizzate."
Ciò crea un problema di gestione della flotta impossibile con gli approcci tradizionali. Non è possibile assumere un numero sufficiente di DBA per effettuare manualmente il provisioning, il monitoraggio e la risoluzione dei problemi di migliaia di database. La soluzione di Xin: trattare la gestione del database stessa come un problema di dati, non come un problema operativo.
Lakebase archivia tutti i dati di telemetria e i metadati (prestazioni delle query, utilizzo delle risorse, modelli di connessione, tassi di errore) direttamente nella Lakehouse, dove possono essere analizzati utilizzando strumenti standard di ingegneria dei dati e scienza dei dati. Invece di configurare dashboard in strumenti di monitoraggio specifici del database, i data team interrogano i dati di telemetria con SQL o li analizzano con modelli di machine learning per identificare valori anomali e prevedere problemi.
"Invece di creare una dashboard ogni 50 o 100 database, puoi effettivamente guardare il grafico per vedere se qualcosa si comporta in modo errato." Xin ha spiegato. "La gestione del database sarà molto simile a un problema di analisi. Guardi i valori anomali, guardi le tendenze, cerchi di capire perché le cose stanno accadendo. In questo modo fornisci una gestione su larga scala mentre gli agenti creano e distruggono i database a livello di codice."
Le conseguenze di ciò si estendono agli stessi agenti autonomi. Un agente AI che riscontra problemi di prestazioni può interrogare i dati di telemetria per diagnosticare i problemi; può trattare le operazioni del database come un’altra attività di analisi anziché richiedere conoscenze DBA specializzate. La gestione del database diventa qualcosa che gli agenti possono fare da soli utilizzando le funzionalità di analisi dei dati di cui già dispongono.
Cosa significa questo per i team dati aziendali?
L’architettura Lakebase segnala un cambiamento fondamentale nel modo in cui le organizzazioni dovrebbero pensare ai propri database operativi; non come infrastrutture preziose e gestite con attenzione che richiedono DBA esperti, ma come risorse temporanee e self-service scalabili a livello di programmazione, come il cloud computing.
Ciò è importante se gli agenti autonomi si realizzeranno con la rapidità prevista da Databricks, perché il principio fondamentale dell’architettura, ovvero trattare la gestione del database come un problema di analisi piuttosto che come un problema operativo, cambia le competenze e le strutture dei team di cui le aziende hanno bisogno.
I leader dei dati devono prestare attenzione alla convergenza dei dati operativi e analitici che si verificano nel settore. Quando ciò che viene scritto in un database operativo può essere immediatamente interrogato da motori di analisi senza ETL, i confini tradizionali tra sistemi transazionali e data warehouse vengono sfumati. Questa architettura unificata riduce il carico operativo derivante dal mantenimento di sistemi separati, ma richiede anche il ripensamento delle strutture dei team dati costruite attorno a questi confini.
Quando fu introdotto Lakehouse, i concorrenti rifiutarono il concetto e alla fine lo adottarono loro stessi. Xin prevede la stessa tendenza per Lakebase.
"Ha senso separare lo storage e il calcolo e mettere tutto lo storage nel lago; consente molte capacità e possibilità," ha detto.
