La rivalità tra Databricks e Google nel settore dei database si intensifica dopo l'acquisizione di Neon

Databricks ha acquisito Neon con un accordo dal valore riportato di miliardi di dollari, portando la competizione tra Databricks e Google nel mercato dei database operativi. L'operazione è stata annunciata nel maggio 2025 e successivamente completata. Le sue conseguenze sono diventate più chiare quando la tecnologia di Neon è apparsa all'interno di Databricks come Lakebase.

Non si è trattato semplicemente dell'ennesima acquisizione di un database. Databricks aveva costruito la propria posizione attorno ad analisi, machine learning e dati archiviati per l'elaborazione su larga scala. Neon le ha fornito un sistema compatibile con PostgreSQL per le transazioni in tempo reale che le applicazioni generano ogni secondo.

Questa mossa avvicina Databricks a Google Cloud, Amazon Web Services, Microsoft e Snowflake. Ciascuna azienda vuole controllare il livello dati alla base degli agenti AI. Google offre già AlloyDB, Cloud SQL, Spanner, BigQuery, Vertex AI e i propri strumenti per lo sviluppo di agenti.

La domanda centrale non è più se Databricks sia in grado di analizzare i dati aziendali. È se Databricks possa diventare il luogo in cui le applicazioni AI creano, aggiornano, governano e analizzano quei dati.

L'accordo con Neon ha colmato una lacuna critica

Neon ha fornito a Databricks un'architettura di database operativo che la sua piattaforma lakehouse non offriva in precedenza.

Databricks ha annunciato l'accordo per acquisire Neon il 14 maggio 2025. Il suo comunicato sull'acquisizione descriveva Neon come un'azienda di PostgreSQL serverless pensata per sviluppatori e agenti AI.

PostgreSQL è un database relazionale open source utilizzato dalle applicazioni per archiviare informazioni strutturate e soggette a frequenti modifiche. Supporta query SQL note, transazioni, estensioni e un ampio ecosistema di sviluppatori.

Neon ha riprogettato PostgreSQL per l'infrastruttura cloud separando il calcolo dallo storage. L'elaborazione del database può scalare in modo indipendente, mentre le informazioni persistenti rimangono in uno storage condiviso. Un carico di lavoro può ridurre le risorse di calcolo inattive, creare rami isolati e predisporre nuovi ambienti senza duplicare un intero database.

Questo modello è importante per il software generato dall'AI. Un team di sviluppo umano potrebbe creare diversi database per produzione, test e staging. Un agente di coding automatizzato può generare molti progetti temporanei, rami, test e istanze di database nello stesso intervallo di tempo.

Neon ha dichiarato che, al momento dell'annuncio dell'operazione, gli agenti AI stavano già creando la maggior parte dei nuovi database del suo servizio. In seguito, il CEO di Databricks Ali Ghodsi ha detto ad Axios che Neon aveva riferito che gli agenti creavano l'80 per cento dei suoi database.

La statistica proveniva da Neon, non da una verifica indipendente. Tuttavia, spiegava la logica strategica. Databricks non stava acquistando la compatibilità con PostgreSQL soltanto per le applicazioni aziendali convenzionali. Stava acquistando un'infrastruttura progettata per la creazione di software alla velocità delle macchine.

I fondatori di Neon perseguivano questa architettura sin dal lancio dell'azienda nel 2021. L'annuncio dell'operazione dell'azienda affermava che il suo obiettivo originario era un servizio PostgreSQL cloud-native che gli sviluppatori avrebbero apprezzato usare.

Per Databricks, Neon ha fornito tre componenti mancanti.

In primo luogo, ha fornito storage transazionale. Databricks si era concentrata sui carichi di lavoro analitici, in cui le aziende elaborano grandi raccolte di dati storici o in streaming. Le applicazioni operative richiedono letture e scritture a minore latenza, con una gestione affidabile delle transazioni.

In secondo luogo, Neon ha fornito un modello di provisioning rivolto agli sviluppatori. Un database può comparire come risorsa applicativa anziché come progetto infrastrutturale gestito manualmente. Questa differenza diventa significativa quando gli agenti creano ambienti automaticamente.

In terzo luogo, Neon ha fornito un punto d'accesso al mercato PostgreSQL. Gli sviluppatori conoscono già strumenti, driver, estensioni e sintassi delle query di PostgreSQL. Databricks poteva estendere la propria piattaforma senza imporre un modello di programmazione del tutto sconosciuto.

L'acquisizione ha inoltre proseguito la strategia di Databricks di acquistare tecnologie fondamentali. MosaicML ha aggiunto capacità di addestramento per l'AI generativa. Tabular ha aggiunto competenze legate ad Apache Iceberg e ai formati di dati aperti. Neon ha aggiunto un database operativo.

Nel complesso, queste operazioni rivelano un'ambizione più ampia. Databricks vuole controllare una porzione maggiore del percorso che conduce dai dati aziendali grezzi alle applicazioni AI in produzione.

L'azienda dipende ancora dall'infrastruttura cloud sottostante. Databricks opera su AWS, Microsoft Azure e Google Cloud. Neon non elimina questa dipendenza. Fornisce a Databricks un ulteriore livello software che può influenzare il modo in cui i clienti utilizzano questi cloud.

Questa distinzione crea la tensione centrale dell'articolo. Databricks rimane partner dei principali fornitori cloud mentre compete sempre più con i loro servizi di database e AI.

Perché la competizione tra Databricks e Google ora include PostgreSQL

Il rapporto tra Databricks e Google combina una partnership infrastrutturale con la competizione diretta per i carichi di lavoro delle applicazioni AI.

Databricks e Google Cloud collaborano da anni. I clienti possono eseguire Databricks su Google Cloud, connetterlo allo storage cloud e integrare i carichi di lavoro con servizi come BigQuery e Vertex AI.

Questa partnership rimane importante dal punto di vista commerciale. Le imprese raramente sostituiscono un intero ambiente cloud perché un fornitore introduce un nuovo database. Spesso combinano infrastruttura, piattaforme dati, modelli e applicazioni di diversi fornitori.

Neon crea comunque pressione competitiva perché Google vende i propri servizi PostgreSQL. Cloud SQL offre PostgreSQL gestito, mentre AlloyDB fornisce un database compatibile con PostgreSQL progettato per carichi di lavoro cloud esigenti.

Google ha inoltre posizionato AlloyDB come fondamento per le applicazioni di AI generativa. La sua roadmap AI di AlloyDB include ricerca semantica, indicizzazione vettoriale, query in linguaggio naturale e connessioni ai servizi di modelli.

Un indice vettoriale organizza rappresentazioni numeriche di testo, immagini o altri contenuti. Le applicazioni usano queste rappresentazioni per recuperare informazioni correlate alla richiesta di un utente.

Il vantaggio di Google deriva dall'integrazione verticale. Un cliente può combinare AlloyDB con modelli Gemini, Vertex AI, controlli di identità, networking, osservabilità e gli strumenti di Google per lo sviluppo di agenti. Un unico fornitore gestisce gran parte dello stack.

Databricks offre una proposta diversa. Si presenta come un livello dati e AI multi-cloud in grado di operare attraverso diversi fornitori di infrastruttura. Lakebase estende questa proposta al PostgreSQL operativo.

Questo crea due percorsi concorrenti per gli acquirenti aziendali.

Il percorso di Google parte dal cloud. Il cliente utilizza infrastruttura Google, database Google, modelli Google e servizi di gestione Google. La profondità dell'integrazione diventa l'attrattiva principale.

Il percorso di Databricks parte dalla piattaforma dati. Il cliente utilizza informazioni governate tramite Databricks, sceglie tra fornitori cloud e di modelli e sviluppa applicazioni accanto ai carichi di lavoro analitici esistenti.

Nessuno dei due approcci elimina la complessità. I clienti Google devono decidere quanto strettamente desiderano integrare le applicazioni con un singolo cloud. I clienti Databricks devono valutare se la sua astrazione cross-cloud offra una sufficiente coerenza operativa.

L'acquisizione di Neon alza la posta perché i database applicativi diventano spesso impegni architetturali duraturi. Spostare un endpoint di modello può essere gestibile. Migrare un database transazionale con anni di dipendenze applicative è considerevolmente più difficile.

La compatibilità con PostgreSQL riduce parte dell'attrito di migrazione. Non garantisce la portabilità. I servizi gestiti introducono autenticazione proprietaria, networking, monitoraggio, branching, replica e integrazioni AI attorno al database principale.

Google può sostenere che AlloyDB offra un'integrazione matura con i suoi controlli cloud e i servizi Gemini. Databricks può sostenere che Lakebase colleghi i dati operativi con analisi, governance e AI all'interno della propria piattaforma.

La differenza diventa concreta in un'applicazione AI per l'assistenza clienti. L'applicazione potrebbe archiviare in PostgreSQL account, stato delle conversazioni, autorizzazioni e stato dei flussi di lavoro. Potrebbe inoltre analizzare interazioni storiche e recuperare documenti pertinenti per un agente.

Con Google, l'applicazione potrebbe combinare AlloyDB, Vertex AI e BigQuery. Con Databricks, Lakebase potrebbe gestire le transazioni mentre la lakehouse supporta analisi, valutazione dei modelli e recupero governato delle informazioni.

L'acquirente sceglie più delle prestazioni del database. La decisione influisce sul luogo in cui risiede lo stato dell'applicazione, sul modo in cui gli agenti ricevono contesto e sulla piattaforma che governa l'accesso.

Ecco perché la parola chiave principale è più ampia di una singola acquisizione. La competizione tra Databricks e Google riflette una lotta per il punto di controllo alla base delle applicazioni AI aziendali.

Databricks non deve sostituire l'infrastruttura Google Cloud per creare pressione. Deve solo indurre i clienti a considerare Databricks come il loro principale piano di controllo per dati e AI.

Gli agenti AI cambiano ciò che un database deve gestire

Il vero valore strategico di Neon risiede nel provisioning, nel branching e nella scalabilità dei database per flussi di lavoro software automatizzati.

Le operazioni tradizionali sui database presuppongono che siano le persone a prendere la maggior parte delle decisioni infrastrutturali. Un ingegnere richiede un database, configura gli accessi, imposta i backup e crea ambienti di sviluppo.

Gli agenti di coding AI comprimono questo ciclo. Possono generare un'applicazione, eseguire test, rivedere schemi e distribuire ambienti di anteprima con un intervento umano limitato. Il livello database deve rispondere senza trasformarsi in un collo di bottiglia amministrativo.

Il provisioning serverless aiuta perché la capacità non deve essere assegnata attraverso un lungo processo manuale. Le risorse di calcolo possono avviarsi quando arriva un carico di lavoro e ridursi quando l'attività si interrompe.

Il branching è altrettanto importante. Un ramo di database fornisce a uno sviluppatore o a un agente un ambiente isolato derivato da uno stato esistente. Le modifiche possono essere testate senza alterare i record di produzione.

Si consideri un agente incaricato di aggiungere la gestione degli abbonamenti a un'applicazione interna. Potrebbe modificare uno schema, creare account di test, eseguire script di migrazione e convalidare query.

Eseguire questi passaggi su un database di produzione sarebbe rischioso. Creare una copia convenzionale per ogni tentativo richiederebbe tempo e storage. Un flusso di lavoro basato sui rami offre un confine più pulito.

L'architettura supporta anche le applicazioni di anteprima. Ogni modifica proposta al codice può ricevere il proprio deployment applicativo e il relativo stato del database. I revisori possono esaminare software funzionante prima che le modifiche raggiungano la produzione.

Questi schemi spiegano perché Databricks desiderasse qualcosa di più del generico hosting PostgreSQL. Neon aveva progettato il proprio servizio attorno alla creazione rapida, al calcolo indipendente e al branching del database.

Lakebase introduce questo design in Databricks. Collega un database operativo compatibile con PostgreSQL a una piattaforma già utilizzata per data engineering, governance, analisi e machine learning.

Il potenziale vantaggio è un percorso più breve tra lo stato in tempo reale di un'applicazione e il suo contesto analitico. Un agente potrebbe usare record transazionali correnti attingendo al contempo informazioni governate da dataset aziendali più ampi.

Databricks chiama Unity Catalog il proprio livello di governance. In questo contesto, la governance comprende individuazione, autorizzazioni, lineage e controlli delle policy per asset di dati e AI.

Un catalogo unificato non risolve automaticamente la sicurezza delle applicazioni. I database operativi hanno utenti, regole di connessione, confini transazionali e modalità di errore propri. Tuttavia, un'identità condivisa e l'integrazione delle policy possono ridurre l'amministrazione duplicata.

Google persegue una meta simile con un'architettura diversa. AlloyDB supporta carichi di lavoro PostgreSQL, mentre Google collega i database a Gemini, Vertex AI e framework per agenti.

La documentazione pubblica di Google descrive AlloyDB AI come una soluzione che supporta la ricerca vettoriale, l'interazione in linguaggio naturale e chiamate a più provider di modelli. Questa ampiezza indebolisce qualsiasi tesi secondo cui Neon offrirebbe a Databricks una categoria di database AI unica.

Neon aiuta invece Databricks a competere sul terreno della progettazione dei flussi di lavoro. L'azienda può affiancare la creazione di database a notebook, pipeline di dati, applicazioni, endpoint dei modelli e record aziendali governati.

Il meccanismo è più importante del titolo dell'acquisizione. Gli agenti AI aumentano il numero di azioni infrastrutturali eseguite per sviluppatore. I database devono diventare risorse programmabili, in grado di comparire, ramificarsi e essere dismesse tramite flussi di lavoro automatizzati.

C'è anche un effetto di gravità dei dati. Quando un'applicazione conserva lo stato live sulla stessa piattaforma utilizzata per analisi e AI, spostare uno dei due carichi di lavoro diventa più difficile.

Databricks ottiene l'opportunità di espandersi negli account esistenti. Un cliente che usa la piattaforma per l'analisi può adottare Lakebase per una nuova applicazione AI. Questa scelta può aumentare il consumo di storage, calcolo, governance e servizi di modelli.

Google si trova di fronte all'opportunità inversa. Un cliente già impegnato su Google Cloud può sviluppare con AlloyDB e Vertex AI senza aggiungere un altro piano di controllo della piattaforma.

La concorrenza tra Databricks e Google ruota quindi attorno alla praticità per gli sviluppatori e al controllo aziendale. Entrambe le aziende vogliono rendere la propria piattaforma il luogo predefinito in cui un'applicazione AI incontra dati aziendali affidabili.

Il database vincente non sarà scelto soltanto in base al branding degli agenti. Dovrà garantire transazioni prevedibili, ripristino, osservabilità, sicurezza di rete, disponibilità regionale e costi gestibili con carichi di lavoro reali.

L'acquisizione non elimina il rischio operativo

Databricks deve ancora dimostrare che l'architettura di Neon, favorevole agli sviluppatori, possa soddisfare su larga scala i requisiti delle aziende in produzione.

L'acquisizione ha portato tecnologia e talenti ingegneristici. Non ha però dato istantaneamente a Databricks decenni di credibilità nella gestione operativa dei database.

Le piattaforme analitiche e i sistemi transazionali falliscono in modo diverso. Una query analitica può talvolta essere ritentata dopo un ritardo. Una transazione fallita può interrompere un pagamento, duplicare un'azione o lasciare incoerente lo stato dell'applicazione.

Gli acquirenti aziendali esamineranno obiettivi di ripristino, replica, comportamento durante la manutenzione, gestione delle connessioni, copertura regionale e isolamento dei carichi di lavoro. Testeranno inoltre le prestazioni durante picchi improvvisi generati dagli agenti.

La separazione tra calcolo e storage offre flessibilità, ma introduce compromessi. Un database deve spostare le informazioni in modo efficiente tra lo storage persistente e il calcolo attivo. Avvii a freddo, comportamento della cache e percorsi di rete possono influire sulla latenza.

Anche il branching richiede controlli chiari. Gli agenti non dovrebbero ottenere accesso illimitato ai record di produzione semplicemente perché possono creare un ambiente di database isolato.

Le organizzazioni avranno bisogno di policy per mascherare informazioni sensibili, limitare la creazione di branch, far scadere le risorse temporanee e sottoporre a audit le modifiche automatizzate. Il numero di ambienti può diventare un problema di governance.

La questione open source aggiunge un'altra incertezza. Neon ha costruito la propria identità attorno a PostgreSQL e a tecnologia pubblicamente disponibile. L'acquisizione da parte di una grande piattaforma può suscitare preoccupazioni sulla compatibilità futura o sulla direzione del prodotto.

Databricks ha una storia radicata in progetti open source, inclusi Apache Spark e Delta Lake. Questo contesto ne sostiene la credibilità, ma i clienti giudicheranno il comportamento, non la storia.

Dovrebbero osservare se lo sviluppo principale di Neon rimane accessibile e se gli strumenti PostgreSQL standard continuano a funzionare senza modifiche significative. Le integrazioni proprietarie possono aggiungere valore aumentando al contempo i costi di migrazione.

Google affronta la stessa questione di fiducia. AlloyDB è compatibile con PostgreSQL, piuttosto che una distribuzione con un comportamento identico in ogni dettaglio. Le sue funzionalità più forti dipendono dall'ambiente gestito di Google.

Le dichiarazioni sulla portabilità da entrambe le parti meritano test accurati. La compatibilità SQL non copre gli strumenti operativi, i sistemi di identità, i backup, l'osservabilità o le estensioni specifiche per l'AI.

La pressione competitiva va anche oltre Google. Snowflake ha acquisito lo specialista PostgreSQL Crunchy Data poco dopo che Databricks aveva annunciato la transazione Neon.

Un documento regolatorio di Snowflake afferma che l'azienda ha completato tale acquisizione nel giugno 2025. La tempistica ha mostrato che PostgreSQL operativo era diventato strategicamente importante per tutte le piattaforme dati.

La risposta di Snowflake impedisce a Databricks di definire da sola il mercato. Può combinare l'esperienza di Crunchy Data con i propri servizi di analisi, applicazioni e AI.

AWS rimane un'altra forza importante grazie ad Amazon Aurora e al suo più ampio portafoglio di database. Microsoft può combinare database Azure, Fabric, servizi Databricks e la propria relazione con OpenAI.

Questo mercato affollato è utile agli acquirenti perché incentiva uno sviluppo più rapido. Rende però anche più difficili i confronti tra prodotti. Ogni provider descrive il proprio database come pronto per gli agenti AI.

Gli acquirenti hanno bisogno di prove legate a carichi di lavoro reali. Una valutazione utile dovrebbe includere latenza delle transazioni, test di ripristino, tempo di creazione dei branch, limiti di connessione, impegno amministrativo e comportamento con domanda variabile.

I team dovrebbero inoltre testare il movimento dei dati. Un'applicazione può richiedere record operativi per analisi, valutazione dei modelli o retrieval. L'architettura dovrebbe mostrare con quale rapidità questi record diventano disponibili e come le policy di governance li seguono.

Le affermazioni dei fornitori sull'adozione degli agenti richiedono una cautela simile. Un database creato da uno strumento automatizzato non supporta necessariamente un'applicazione di produzione di valore.

Le metriche importanti sono crescita sostenuta dei carichi di lavoro, database di produzione attivi, retention, affidabilità ed espansione dei clienti. Databricks non ha fornito pubblicamente dettagli sufficienti per risolvere tali questioni.

Esiste anche un rischio di integrazione strategica. I prodotti acquisiti possono perdere slancio quando i team trascorrono mesi ad adattare sistemi di autenticazione, fatturazione, supporto e governance.

Neon ha continuato a pubblicare aggiornamenti di prodotto dopo l'ingresso in Databricks, il che suggerisce uno sviluppo attivo. Tuttavia, la continuità dei rilasci non dimostra che ogni cliente Databricks possa adottare Lakebase senza compromessi architetturali.

Un'analisi indipendente ha descritto l'acquisizione come un passo che ha avvicinato Databricks agli hyperscaler. Una valutazione dei database ha osservato che le capacità PostgreSQL hanno esteso Databricks oltre la sua tradizionale concorrenza nella gestione dei dati.

Questa espansione è strategicamente interessante, ma innalza le aspettative. Databricks deve ora competere con provider che gestiscono database business-critical da molti anni.

L'acquisizione ha reso Databricks un partecipante credibile a questa competizione. Le prove in produzione determineranno se diventerà un leader duraturo nel settore dei database.

Tre segnali mostreranno chi sta guadagnando terreno

Disponibilità del prodotto, adozione in produzione e integrazione competitiva determineranno se Neon cambierà il mercato.

Il primo segnale è l'adozione di Lakebase dopo la disponibilità generale. L'interesse nella fase di anteprima può riflettere sperimentazione, mentre l'uso in produzione richiede revisioni della sicurezza, test operativi e impegno organizzativo.

I clienti dovrebbero cercare implementazioni nominate che supportino applicazioni rivolte ai clienti. I casi più solidi includeranno caratteristiche misurabili dei carichi di lavoro, requisiti di ripristino e integrazione con la governance di Databricks.

Un'espansione ripetuta negli account Databricks esistenti rafforzerebbe la strategia dell'azienda. Dimostrerebbe che i clienti dell'analisi vedono valore nell'aggiungere carichi di lavoro operativi alla stessa piattaforma.

Un'adozione limitata indebolirebbe la tesi. Suggerirebbe che le aziende preferiscono servizi di database consolidati, anche quando utilizzano Databricks per analisi e AI.

Il secondo segnale è la risposta di Google attraverso AlloyDB e la sua piattaforma per agenti. Google dispone già di un ampio portafoglio di database, quindi la sua risposta non deve fare riferimento diretto a Databricks.

Gli indicatori significativi sono collegamenti più stretti tra AlloyDB, Gemini, strumenti per agenti, BigQuery e servizi di governance. Google può rendere l'integrazione verticale la sua risposta più forte a Databricks.

Le sue funzionalità AI per PostgreSQL comprendono ora retrieval vettoriale, query in linguaggio naturale, connessioni ai modelli e flussi di lavoro orientati agli agenti. Un'integrazione continua rafforzerebbe la posizione di Google presso i clienti già impegnati sul suo cloud.

Databricks può rispondere attraverso una coerenza multi-cloud. Se Lakebase si comporta in modo simile su AWS, Azure e Google Cloud, i clienti ottengono un'alternativa all'architettura applicativa specifica di un singolo provider.

Questa affermazione necessita di una verifica operativa. Date di disponibilità, copertura regionale, funzionalità di rete e opzioni di disaster recovery possono differire tra i cloud.

Il terzo segnale riguarda il modo in cui Snowflake e altri provider confezionano PostgreSQL. L'acquisizione di Crunchy Data da parte di Snowflake ha confermato che Databricks non era l'unica a identificare i database operativi come un livello mancante.

Occorre osservare se Snowflake Postgres diventerà un servizio di produzione strettamente collegato alla sua piattaforma dati. Una forte adozione dividerebbe la domanda aziendale e indebolirebbe qualsiasi semplice narrazione basata su due aziende.

AWS può esercitare pressione su ogni partecipante attraverso Aurora, Bedrock e la sua consolidata base di sviluppatori. Microsoft può combinare i servizi di database Azure con Fabric e Azure Databricks.

La competizione si svilupperà quindi su diverse dimensioni. L'affidabilità del database rimane fondamentale, ma governance della piattaforma, scelta dei modelli, flusso di lavoro degli sviluppatori e portabilità cloud influenzano ora lo stesso acquisto.

Per gli sviluppatori, il vantaggio immediato è una maggiore scelta. Un team può confrontare offerte PostgreSQL integrate senza abbandonare SQL, librerie e strumenti familiari.

Per gli acquirenti aziendali, la decisione ha conseguenze più durature. Il database operativo diventa spesso il sistema di record di un'applicazione. La piattaforma che lo circonda può modellare sicurezza, analisi e sviluppo AI per anni.

Per i team che sviluppano prodotti AI, il branching dei database merita particolare attenzione. Gli agenti che modificano software hanno bisogno di ambienti dati isolati, credenziali controllate e pulizia automatizzata. Un database progettato per un provisioning a ritmo umano può rallentare l'intero flusso di lavoro.

La rivalità tra Databricks e Google non sarà risolta da un singolo benchmark o da un'acquisizione. Sarà risolta da ripetute decisioni di produzione su dove gli agenti archiviano lo stato e accedono a informazioni governate.

La transazione Neon è importante perché ha cambiato il ruolo di Databricks. L'azienda non offre più soltanto l'ambiente analitico accanto a un database applicativo. Ora vuole fornire entrambi.

Google conserva ancora importanti vantaggi in termini di portata dell'infrastruttura e servizi cloud integrati. Databricks occupa una posizione forte all'interno dei team dati aziendali e può operare sui maggiori cloud.

Questo crea un conflitto produttivo. Google vuole che la piattaforma cloud organizzi lo stack AI. Databricks vuole che la piattaforma dati diventi quel livello organizzativo.

I team che valutano una delle due strade dovrebbero iniziare da un'applicazione reale anziché da una checklist di funzionalità. Testate il comportamento delle transazioni, l'isolamento dei branch, il ripristino, la governance e l'integrazione dei modelli con la domanda prevista.

Chiedetevi quindi chi controlla il contesto più importante. Se la risposta è il fornitore cloud, il percorso integrato di Google diventa interessante. Se la risposta è la piattaforma dati, Databricks acquista maggiore leva.

L’acquisizione ha trasformato quella scelta architetturale in una decisione d’acquisto immediata. Tenete d’occhio le implementazioni di Lakebase in produzione, una più profonda integrazione con AlloyDB e il lancio di PostgreSQL da parte di Snowflake. Questi segnali mostreranno se Databricks ha costruito un business duraturo nel settore dei database o se è semplicemente entrata in una corsa affollata.