Pipeline ETL: perché costano troppo e perché il mercato vuole eliminarle?
Da decenni, ogni organizzazione che lavora con i dati convive con una scissione strutturale: da una parte i sistemi transazionali (OLTP), che gestiscono le operazioni quotidiane — ordini, account, eventi in tempo reale — dall'altra i sistemi analitici (OLAP), data warehouse e data lake dove i dati vengono interrogati per produrre insight. In mezzo, una selva di pipeline ETL (Extract, Transform, Load) costruite per tenerli sincronizzati.
Il costo di questa architettura è tutt'altro che trascurabile. Secondo le stime di Airbyte, un progetto ETL su scala enterprise può arrivare a costare tra i 100.000 e i 400.000 dollari nella fase di implementazione iniziale, con costi di manutenzione annuali che nelle grandi organizzazioni superano i 100.000 dollari. Il dato più significativo, però, viene dall'aspetto umano: la manutenzione manuale delle pipeline consuma tra il 60% e l'80% del tempo di un data engineer — un overhead che lascia pochissimo spazio all'innovazione. Il mercato ETL complessivo valeva 7,6 miliardi di dollari nel 2024 ed è proiettato verso i 29 miliardi entro il 2029: una misura di quanto denaro si spende globalmente per far parlare sistemi che, in un'architettura ideale, non dovrebbero essere separati.
(Media Stime Airbyte)
È in questo contesto che Databricks ha presentato — e reso generalmente disponibile a febbraio 2026 — Lakebase, un database PostgreSQL serverless integrato nativamente nella sua piattaforma Lakehouse, affiancato da Databricks Apps, un runtime per il deploy di applicazioni data-driven. L'ambizione è esplicita: una piattaforma full-stack capace di coprire sia i workload analitici che quelli transazionali, senza duplicare i dati e senza costruire pipeline fragili tra i due mondi.
Databricks nel 2026: $134B di valutazione e la sfida al mercato OLTP
Databricks non è un progetto emergente. A febbraio 2026, la società ha completato un round Series L che l'ha valutata 134 miliardi di dollari, dopo aver dichiarato un fatturato annualizzato superiore ai 5,4 miliardi di dollari nel trimestre di gennaio, con una crescita anno su anno del 65%. Per confronto, il suo principale concorrente Snowflake — quotata in borsa — vale circa la metà in capitalizzazione di mercato pur avendo ricavi leggermente superiori, ma crescendo a un ritmo molto più lento (circa il 27% annuo).
La catena Zero ETL è il vero cambio di paradigma
Prima di entrare nelle singole componenti tecniche, vale la pena capire la logica d'insieme — perché è lì che risiede la proposta di valore più originale.
L'architettura Databricks introduce una catena Zero ETL a doppio senso che, almeno sulla carta, elimina la necessità di costruire pipeline personalizzate in quattro punti critici:
- Lakehouse → Lakebase (Reverse ETL senza codice). I dati analitici elaborati su Delta Lake vengono sincronizzati direttamente in tabelle PostgreSQL su Lakebase, rendendoli accessibili con latenza sub-10ms alle applicazioni operative — senza costruire connector custom.
- Lakebase → Lakehouse (Change Data Capture). Le scritture transazionali delle applicazioni operative fluiscono verso il Lakehouse per alimentare le pipeline analitiche, chiudendo il ciclo senza duplicazione dello storage.
- Lakehouse → Unity Catalog (catalogazione automatica). Ogni asset del Lakehouse — tabella Delta, modello ML, endpoint LLM — viene registrato automaticamente nel catalogo unificato con schema, lineage e metadati. Questo è il momento in cui i dati diventano accessibili in modo strutturato non solo agli analisti umani, ma anche agli agenti AI.
- Unity Catalog → Agenti AI (contesto zero-setup). Gli agenti AI interrogano Unity Catalog per scoprire automaticamente quali dati esistono, come sono strutturati, chi può accedervi e come si relazionano tra loro. Non è solo governance: è la "memoria semantica" che rende un agente AI capace di ragionare sul dato aziendale senza che qualcuno costruisca manualmente un indice RAG separato. Zero ETL applicato al contesto agentivo.
Questa catena — facilità di sviluppo AI (Vibe Coding + Databricks Apps), solidità transazionale (Lakebase/PostgreSQL), zero ETL analitico (Delta Lake), zero ETL per il contesto agentivo (Unity Catalog) — è il filo che connette tutti i componenti. Il resto dell'articolo analizza ciascuno nel dettaglio.
Il database PostgreSQL serverless integrato nel Lakehouse
Tecnicamente, Lakebase è il risultato dell'acquisizione di Neon — una startup specializzata in PostgreSQL cloud-native — per circa un miliardo di dollari nel maggio 2025, successivamente integrata con Mooncake per migliorare il collegamento tra PostgreSQL e Delta Lake. Il prodotto è disponibile in due varianti: Provisioned (già GA) e Autoscaling (ancora in public preview su AWS), con quest'ultima che introduce database branching, scale-to-zero e instant restore.
L'architettura centrale è la separazione tra compute e storage, mutuata dal mondo Lakehouse. Questo consente di scalare le due dimensioni indipendentemente, sospendere il compute quando non in uso e garantire alta disponibilità attraverso failover multi-AZ e repliche secondarie leggibili. Il point-in-time recovery è supportato fino a 35 giorni, basato su cloning copy-on-write.
Dal punto di vista del workload, Lakebase è ottimizzato per pattern OLTP: letture e scritture a livello di singola riga ad alta frequenza, con latenza target sotto i 10 millisecondi e throughput superiori a 10.000 query al secondo. Un team di ricercatori di CBTW ha verificato empiricamente che Lakebase mantiene latenze nell'ordine dei pochi millisecondi per operazioni di lettura, aggiornamento e inserimento — un risultato significativo rispetto alle latenze tipiche di un SQL Warehouse Databricks, pensato per query analitiche su larga scala, non per accessi puntuali a singola riga.
Il collegamento con il Lakehouse avviene attraverso Lakeflow, che gestisce la sincronizzazione incrementale tra tabelle Delta Lake e istanze Lakebase PostgreSQL in modalità continua, schedulata o snapshot. Il punto architetturalmente più rilevante: un'applicazione può leggere da Lakebase con latenza sub-10ms, mentre i dati originano da pipeline analitiche su Delta Lake — eliminando, almeno in teoria, la necessità di reverse ETL custom.
Le estensioni supportate nativamente includono pgvector (essenziale per ricerca semantica e architetture RAG) e PostGIS, il che rende Lakebase utilizzabile anche come vector store per sistemi agentici che necessitano di similarità semantica accanto ai dati transazionali.
Database branching: versionare il database come codice
Una delle funzionalità meno discusse ma architetturalmente più interessanti di Lakebase è il database branching. Analogamente al branching del codice sorgente in Git, è possibile creare istantaneamente un "ramo" del database di produzione per sviluppo o testing, isolato dal workload live. Quando il branch non è più necessario, viene eliminato senza impatto sulla produzione; se serve tornare allo stato precedente, il reset è immediato.
Questa capacità trasforma il database da entità monolitica a oggetto versionabile, aprendo pattern di sviluppo finora riservati al software: feature branch con dati reali per test di integrazione, ambienti di staging fedeli alla produzione senza duplicazione fisica dei dati, rollback chirurgici su ambienti di sviluppo. Per i team che già lavorano con infrastruttura-as-code e CI/CD, è un'integrazione naturale nel workflow esistente.
Unity Catalog: governance RBAC e memoria semantica per gli agenti AI
Unity Catalog è il layer che tiene insieme l'intera architettura — ma il suo ruolo va ben oltre quello di un semplice registro delle policy di accesso.
- Governance cross-layer. Un'applicazione deployata tramite Databricks Apps eredita automaticamente le policy RBAC definite in Unity Catalog. Se un utente non ha il permesso di vedere certi dati, l'applicazione — e il database Lakebase sottostante — applica la stessa restrizione senza che lo sviluppatore debba reimplementare la logica di autorizzazione nel frontend. Lo stesso vale per le mascherature dinamiche dei dati sensibili: si definiscono una volta nel catalogo, si applicano ovunque.
- Lineage automatico. Unity Catalog traccia automaticamente come i dati si muovono attraverso i layer — dall'ingestion al Lakehouse, dal Lakehouse a Lakebase, da Lakebase alle applicazioni. Questo lineage è consultabile sia dagli amministratori (per compliance e auditing) sia dagli agenti AI (per capire la provenienza di un dato prima di utilizzarlo in una raccomandazione).
- Contesto semantico per agenti AI. Questo è il punto che le narrative di marketing tendono a sottovalutare. Quando un agente AI deve rispondere a una domanda sul dato aziendale, ha bisogno di sapere: quali tabelle esistono, cosa contengono, come si relazionano, chi le può leggere, quanto sono aggiornate. Unity Catalog, integrato con le descrizioni delle colonne, i tag e i metadati di lineage, diventa la fonte di questa conoscenza strutturata — la "memoria semantica" su cui l'agente costruisce il suo ragionamento. Senza Unity Catalog come layer semantico, costruire un agente AI affidabile sui dati aziendali richiede la costruzione manuale di un indice RAG custom, con tutti i rischi di aggiornamento e coerenza che ne derivano.
Databricks Apps e Vibe Coding: deploy serverless con governance Unity Catalog
Databricks Apps è l'ambiente di esecuzione serverless che permette di deployare applicazioni Python direttamente all'interno della piattaforma. Supporta i framework più diffusi nell'ecosistema data — Streamlit, Gradio, Dash — e si integra con Visual Studio Code, PyCharm e pipeline CI/CD via Git. Il provisioning del compute è automatico.
Il termine Vibe Coding — già in uso nella comunità developer — descrive l'uso di agenti AI (come Cursor o GitHub Copilot) per generare codice applicativo in modo interattivo, iterando rapidamente su bozze funzionanti piuttosto che scrivere tutto da zero. Databricks lo contestualizza nella sua piattaforma attraverso il concetto di Context Engineering: invece di prompt generici, lo sviluppatore fornisce all'agente AI il contesto specifico — schemi Lakebase, documentazione API Databricks, snippet funzionanti — ottenendo codice che si connette nativamente al database aziendale senza vulnerabilità o assunzioni errate.
In pratica, il workflow proposto è: un agente AI genera il 70-90% del codice dell'applicazione a partire dai metadati di Unity Catalog e dagli schemi Lakebase; lo sviluppatore integra, testa su un branch del database, e deploya su Databricks Apps con governance già incorporata. Vale la pena notare che "Vibe Coding" è un termine che funziona bene con un pubblico di sviluppatori, ma che richiede una spiegazione esplicita in contesti dove gli interlocutori sono CIO o IT manager più orientati ai processi che alla cultura DevOps.
Snowflake, Aurora, AlloyDB: il mercato del PostgreSQL enterprise si affollla
Un elemento che manca nella narrativa Databricks è il riconoscimento del panorama competitivo. La convergenza OLTP/OLAP non è un'idea nuova, e Databricks non è l'unico player a muoversi in questa direzione.
Snowflake ha risposto con Unistore e le Hybrid Tables, che introducono capacità transazionali nell'ecosistema analitico. Non è un'architettura equivalente a Lakebase — Snowflake rimane fondamentalmente OLAP-first — ma per molti use case operativi è sufficiente. Ancor più significativo: tre settimane dopo l'acquisizione di Neon da parte di Databricks, Snowflake ha acquisito Crunchy Data per aggiungere un database PostgreSQL al suo stack. La guerra del Postgres enterprise è appena iniziata.
AWS Aurora PostgreSQL è già un database cloud-native maturo, con separazione compute/storage e ottima latenza transazionale. Il suo limite è l'isolamento analitico: i dati Aurora non sono nativamente interrogabili da Spark o Databricks SQL senza pipeline intermedie. Ma per un'organizzazione che non è già dentro Databricks, Aurora rimane una scelta solida e consolidata, con anni di maturità operativa alle spalle.
Google AlloyDB e Microsoft Fabric offrono approcci simili di convergenza OLTP/OLAP all'interno dei rispettivi cloud. Fabric in particolare — con la sua architettura OneLake e il supporto nativo a Spark, SQL e Power BI — è il concorrente più diretto a livello di vision architetturale, anche se parte da una base di data warehouse tradizionale piuttosto che da un Lakehouse.
Come nota TechTarget citando analisti di settore, le vere differenze tra questi sistemi emergeranno nell'integrazione di piattaforma e nell'esperienza operativa quotidiana — non nelle feature list, che si stanno rapidamente allineando tra tutti i vendor.
Vendor lock-in, preview instability e curva di adozione: i rischi reali di Lakebase
Managed PostgreSQL vs. self-managed. Lakebase è un managed PostgreSQL, il che comporta alcune limitazioni rispetto a un'installazione self-managed: alcune estensioni avanzate o funzionalità che richiedono accesso superuser potrebbero non essere disponibili nell'ambiente gestito. Per la maggior parte delle applicazioni standard è irrilevante; per use case particolari vale la pena verificare prima di architettare su questo assunto.
Autoscaling in preview. La variante Autoscaling — che include database branching, scale-to-zero e instant restore — è ancora in public preview su AWS, non in GA. Chi vuole affidarsi a queste funzionalità in produzione deve mettere nel conto la possibilità di cambiamenti di comportamento o pricing durante il periodo di preview.
Vendor lock-in strutturale. L'integrazione nativa tra Lakebase, Delta Lake, Unity Catalog e Databricks Apps è il punto di forza dell'architettura, ma è anche la sua dipendenza più profonda. Migrare fuori da questo ecosistema una volta adottato non è banale: i dati sono su Delta Lake, le policy su Unity Catalog, le applicazioni su Databricks Apps. Per le organizzazioni che valorizzano gli open standard e la portabilità — e che già oggi usano Apache Iceberg invece di Delta Lake — questa concentrazione su un singolo vendor è un rischio architetturale da valutare esplicitamente. Delta Lake è open source, ma l'ecosistema attorno è proprietario.
Maturità operativa e curva di adozione. Databricks ha storicamente attratto profili tecnici avanzati. La sua UX non è mai stata il punto di forza rispetto a Snowflake, che ha saputo conquistare i business analyst grazie alla semplicità dell'interfaccia SQL. Lakebase e Apps abbassano la barriera per costruire applicazioni operative su Databricks, ma richiedono comunque competenze sulla piattaforma che non si acquisiscono in pochi giorni — e un'organizzazione che parte da zero dovrà investire significativamente in formazione e change management prima di vedere i benefici.
Agenti AI e Human-in-the-Loop: il pattern architetturale su Lakebase e Unity Catalog
L'architettura proposta da Databricks per sistemi agentici con supervisione umana — il cosiddetto "human-in-the-loop" — è concettualmente coerente e tecnicamente ben costruita. Il flusso è il seguente: un agente AI elabora dati in streaming dal Lakehouse, usando Unity Catalog come fonte di contesto semantico per capire la struttura e il significato dei dati. Produce una raccomandazione — ad esempio, autorizzare un rimborso — e la sincronizza via Lakeflow su Lakebase. Un operatore umano visualizza la raccomandazione attraverso un'applicazione Databricks Apps che legge da Lakebase con latenza sub-10ms. L'approvazione o il rifiuto viene riscritto transazionalmente su Lakebase, chiudendo il ciclo senza che il dato esca mai dal perimetro governato da Unity Catalog.
Questo pattern è genuinamente difficile da implementare in modo sicuro con architetture tradizionali. La latenza di Lakebase rende praticabile un'interfaccia operativa in tempo reale su dati che originano da pipeline analitiche. La governance unificata elimina la necessità di replicare le policy di accesso tra sistemi eterogenei. Il ruolo di Unity Catalog come layer di contesto semantico riduce la quantità di "prompt engineering" necessaria per far funzionare l'agente correttamente.
La domanda aperta è quanto questo pattern si presti alla variabilità dei contesti enterprise reali, dove legacy system, requisiti di compliance giurisdizionali e vincoli di latenza possono discostarsi significativamente dai casi d'uso illustrati nelle demo.
Convergenza OLTP-OLAP: perché Lakebase conta, e cosa manca ancora
Databricks Lakebase e Apps rappresentano un passo architetturalmente rilevante verso la convergenza OLTP/OLAP. La tecnologia è concreta — Lakebase è GA, le performance verificate da terzi sono coerenti con le promesse, il database branching introduce un pattern di sviluppo genuinamente nuovo per il mondo dei dati, e la catena Zero ETL che collega Lakehouse, Lakebase, applicazioni operative e agenti AI attraverso Unity Catalog risolve problemi reali che le organizzazioni affrontano quotidianamente.
Al tempo stesso, chi valuta questa piattaforma dovrebbe farlo con alcune domande esplicite sul tavolo: qual è il costo reale del lock-in su un ecosistema proprietario? Quanto pesa la curva di adozione per team non ancora nativi Databricks? Snowflake, AWS e i hyperscaler stanno convergendo sullo stesso problema — quali saranno le differenze operative effettive tra 12-18 mesi, quando le feature list si saranno ulteriormente allineate?
Il mercato, per ora, sembra aver già preso posizione. Una valutazione privata di 134 miliardi di dollari con crescita al 65% non si giustifica solo con le pipeline ETL risparmiate — ma con la scommessa che Databricks diventi lo strato fondamentale su cui le grandi organizzazioni costruiranno la loro infrastruttura AI nei prossimi cinque anni. Se quella scommessa è giusta, Lakebase e Apps non sono un prodotto ma un layer strategico. Se non lo è, la storia dell'IT aziendale è piena di piattaforme full-stack che hanno finito per complicare più di quanto abbiano semplificato.
Fonti e riferimenti
- Databricks Lakebase — pagina prodotto: https://www.databricks.com/product/lakebase
- Databricks Apps — pagina prodotto: https://www.databricks.com/product/databricks-apps
- InfoQ, "Databricks Introduces Lakebase, a PostgreSQL Database for AI Workloads" (febbraio 2026): https://www.infoq.com/news/2026/02/databricks-lakebase-postgresql/
- TechTarget, "Databricks launches PostgreSQL Lakebase to aid AI developers": https://www.techtarget.com/searchdatamanagement/news/366638723/Databricks-launches-PostgreSQL-Lakebase-to-aid-AI-developers
- CBTW, "Achieving Millisecond Latency in Databricks Apps with Lakebase": https://cbtw.tech/insights/achieving-millisecond-latency-in-databricks-apps-with-lakebase
- SaaStr, "Databricks vs. Snowflake at $5B ARR" (dicembre 2025): https://www.saastr.com/databricks-vs-snowflake-at-5b-arr-same-revenue-2x-valuation-gap-heres-why/
- Airbyte, "How to Calculate ETL Costs": https://airbyte.com/data-engineering-resources/how-to-calculate-the-cost-of-running-etl-workloads
- Hevo Data, "ETL Trends 2026": https://hevodata.com/learn/etl-trends/
- Wing Venture Capital, "Comparing the financials of Databricks and Snowflake": https://www.wing.vc/content/comparing-the-financials-of-databricks-and-snowflake
- HyperFRAME Research, "Databricks Raises $4B at $134B Valuation" (dicembre 2025): https://hyperframeresearch.com/2025/12/19/databricks-raises-4b-at-134b-valuation-as-growth-in-ai-and-lakehouse-momentum-continues/
- Databricks Release Notes, dicembre 2025: https://docs.databricks.com/aws/en/release-notes/product/2025/december
Ti è piaciuto quanto hai letto? Iscriviti a MISPECIAL, la nostra newsletter, per ricevere altri interessanti contenuti.
Iscriviti a MISPECIAL
