Databricks sta migliorando la cache di calcolo di Lakebase Postgres, ma l'autoscaling è il vero banco di prova

Databricks sta migliorando le prestazioni della cache di calcolo di Lakebase Postgres con una nuova configurazione che, nelle misurazioni in produzione dell'azienda, ha raggiunto fino al doppio del throughput. La modifica è già attiva sui compute Databricks a dimensione fissa con almeno 80 unità di calcolo. Resta però irrisolto il problema più complesso: applicare la stessa strategia di memoria ai compute che si espandono e si riducono mentre Postgres è in esecuzione.

L'aggiornamento modifica il punto in cui risiedono più a lungo le pagine di database richieste più frequentemente. I grandi compute a dimensione fissa ora destinano fino al 75% della memoria disponibile ai shared buffer di Postgres. Questi buffer sono la cache in memoria più veloce del motore di database. Databricks supporta inoltre questa memoria con huge page da 2 MB per ridurre il lavoro di traduzione degli indirizzi all'interno del sistema operativo.

Questa combinazione affronta una tensione centrale dei database disaggregati. Separare lo storage durevole dal compute consente riavvii rapidi, scalabilità indipendente e object storage economico. Tuttavia, aumenta anche la distanza tra una query in esecuzione e i dati di cui necessita. Amazon Aurora, AlloyDB e altri database cloud affrontano versioni di questo problema, ma Databricks sta applicando la propria soluzione all'architettura Neon alla base di Lakebase.

Il miglioramento della cache di calcolo di Lakebase Postgres parte dai compute fissi

Databricks ha spostato la parte più calda della cache di Lakebase dal disco locale alla memoria di Postgres, ma solo su macchine a dimensione fissa sufficientemente grandi.

La modifica è stata resa pubblica il 9 settembre 2026. Secondo l'aggiornamento della cache di calcolo dell'azienda, è attiva sui compute Lakebase a dimensione fissa con almeno 80 unità di calcolo. L'equivalente rilascio di Neon copre i compute fissi con almeno 18 unità di calcolo.

Lakebase utilizza storage disaggregato, il che significa che il compute Postgres e lo storage durevole dei dati operano come livelli separati. Un nodo compute esegue il motore di database, ma non possiede la copia autorevole dei dati. Questo design consente agli operatori di sostituire, riavviare o ridimensionare il compute senza spostare un intero database.

Le letture attraversano una gerarchia. Postgres verifica prima i shared buffer in DRAM. Se la pagina è assente, la configurazione precedente controlla una cache di file locale archiviata sull'unità NVMe del nodo compute. Un ulteriore miss invia la richiesta al livello di storage distribuito, dove i pageserver ricostruiscono e restituiscono le pagine del database.

Quella cache di file locale risolveva un importante problema iniziale. Le installazioni Postgres standard beneficiano normalmente sia dei shared buffer sia della page cache del sistema operativo. Lakebase non instrada le letture di pagine remote attraverso un filesystem locale convenzionale, quindi non può dipendere dal normale secondo livello.

Databricks e Neon hanno quindi creato la cache di file locale come sostituto elastico. Poteva occupare capacità oltre l'allocazione statica dei buffer Postgres e adattarsi al compute serverless. Questa configurazione supportava l'autoscaling senza richiedere a Postgres di ridimensionare i shared buffer durante l'esecuzione.

Tuttavia, la configurazione precedente limitava i shared buffer a circa 1 GB. Gran parte della restante capacità della cache di calcolo, che poteva raggiungere il 75% della DRAM, veniva destinata alla cache di file locale. Sulle macchine più grandi, questo bilanciamento inviava molte letture altrimenti memorizzabili nella cache attraverso NVMe anziché la memoria.

La nuova configurazione per compute fissi rimuove la cache di file locale da questo percorso. Assegna il 75% della DRAM ai shared buffer, mantenendo un insieme di lavoro molto più ampio all'interno di Postgres. Secondo l'annuncio, un endpoint Databricks da 80 unità dovrebbe riportare 120 GB quando un amministratore esegue show shared_buffers.

L'accesso alla DRAM evita l'input e output su disco richiesto dalla cache locale. Offre inoltre a Postgres una conoscenza diretta delle pagine memorizzate nella cache e del loro utilizzo. Una cache del sistema operativo o un livello disco separato dispone di meno informazioni sullo stato del database quando deve decidere quale pagina espellere.

Questo è il significato immediato del miglioramento della cache di calcolo di Lakebase Postgres. Non si tratta di un nuovo indice, query planner o formato di storage. Databricks ha modificato l'allocazione della memoria e i meccanismi di memoria virtuale che circondano l'attuale motore di esecuzione Postgres.

L'ambito è importante. Le implementazioni a dimensione fissa possono allocare i shared buffer all'avvio perché il loro limite di memoria resta noto. Gli endpoint con autoscaling non possono fare la stessa ipotesi. La loro memoria disponibile cambia in base alla domanda del carico di lavoro, mentre l'impostazione standard di Postgres rimane statica dopo l'avvio.

Ecco perché il primo rilascio è significativo senza essere completo. Databricks ha dimostrato che un uso più diretto della memoria può migliorare i grandi endpoint Lakebase. Non ha ancora fornito lo stesso design per l'intero modello operativo serverless che rende attraente Postgres disaggregato.

Perché le prestazioni della cache di Lakebase sono diventate una priorità

La separazione dello storage crea flessibilità operativa, ma ogni cache miss rivela i costi di latenza e CPU nascosti da tale flessibilità.

Postgres tradizionale combina di solito il motore di query, il write-ahead log e i file di database su una sola macchina o su storage strettamente connesso. Il sistema operativo può conservare nella propria page cache le pagine di file consultate di recente. Postgres mantiene inoltre pagine selezionate nei shared buffer.

Questa configurazione può duplicare i dati in memoria. Databricks fornisce l'esempio di una macchina con 4 GB di RAM e 1 GB assegnato ai shared buffer. Leggere 1 GB attraverso il filesystem può lasciare un'altra copia nella cache del sistema operativo, consumando 2 GB per memorizzare nella cache 1 GB di pagine di database.

Lakebase modifica il percorso. La sua architettura di storage divide il sistema tra compute Postgres stateless e un servizio di storage durevole. I safekeeper replicano i record del write-ahead log, mentre i pageserver ricostruiscono le versioni delle pagine e le persistono nell'object storage.

L'architettura consente al compute di scalare indipendentemente dai dati archiviati. Supporta funzionalità come scale-to-zero, branching rapido, repliche di lettura e failover senza copiare un intero database. Questi vantaggi dipendono dal mantenimento dello stato durevole al di fuori del nodo compute.

Tuttavia, il compute stateless necessita comunque di avere lo stato a portata di mano durante l'elaborazione delle query. Le applicazioni accedono ripetutamente a indici, pagine di tabelle, record di catalogo e altre strutture. Se tali pagine restano in DRAM, le letture si completano attraverso la parte a minore latenza della gerarchia.

Un miss nei shared buffer segue un percorso più lungo. La cache NVMe locale è più veloce dello storage remoto, ma richiede comunque accesso al disco ed elaborazione software aggiuntiva. Un miss in quel livello raggiunge il pageserver, aggiungendo potenzialmente traffico di rete e lavoro di ricostruzione delle pagine.

La pressione risultante ricade sui team che utilizzano grandi istanze Lakebase per applicazioni sensibili alla latenza. Questi clienti assegnano quantità sostanziali di memoria, ma il precedente limite di 1 GB dei shared buffer impediva a Postgres di utilizzare gran parte di quella memoria attraverso il percorso di cache più veloce.

Il disallineamento diventa più visibile man mano che cresce l'insieme di lavoro. Un insieme di lavoro è la raccolta di pagine a cui un'applicazione accede frequentemente in un determinato periodo. Quando supera la piccola cache in memoria, le richieste finiscono in livelli più lenti anche se la macchina dispone di ampia DRAM.

Databricks aveva bisogno di una risposta migliore perché Lakebase ora supporta carichi di lavoro operativi, non solo job analitici. Le applicazioni rivolte agli utenti tengono conto della tail latency, che riflette le richieste più lente verso l'estremità alta di una distribuzione della latenza. Le medie possono rimanere accettabili mentre le richieste p99 continuano a creare pause visibili.

Anche le applicazioni AI esercitano una pressione disomogenea sui database operativi. Un agente può innescare picchi di recuperi, scritture, checkpoint e chiamate simultanee agli strumenti. Un comportamento prevedibile della cache diventa più importante quando il traffico arriva a gruppi anziché attraverso un flusso costante di richieste.

Questo non significa che ogni carico di lavoro ne benefici allo stesso modo. Un dataset che rientra già nella precedente allocazione dei shared buffer ha meno margine di miglioramento. Un carico di lavoro dominato dalle scansioni con scarso riutilizzo delle pagine potrebbe continuare a raggiungere livelli di cache inferiori indipendentemente dalla dimensione del buffer.

I candidati più adatti sono endpoint di grandi dimensioni con insiemi di lavoro riutilizzabili che superavano il precedente limite di 1 GB. La loro memoria esistente può ora contenere più pagine calde direttamente all'interno di Postgres. È per questo che Databricks ha presentato esempi di produzione anziché promettere un raddoppio universale.

Le prestazioni della cache di Lakebase dipendono quindi dalla forma del carico di lavoro tanto quanto dalle dimensioni della macchina. La nuova configurazione rimuove un collo di bottiglia architetturale. Non elimina le regole di base che governano la località della cache, la progettazione delle query, l'indicizzazione o la contesa della memoria.

Le huge page rendono pratico il pool di buffer più ampio

Allocare più memoria a Postgres creerebbe un proprio overhead se Lakebase non riducesse anche il costo della mappatura di quella memoria tra i processi del database.

Postgres utilizza un'architettura basata su processi. Ogni connessione attiva riceve generalmente un processo backend, e ogni backend mappa la regione dei shared buffer nel proprio spazio di indirizzi virtuale. Il sistema operativo gestisce voci della tabella delle pagine che traducono tali indirizzi virtuali in posizioni della memoria fisica.

Le pagine di memoria Linux standard sono comunemente da 4 KB. Con questa dimensione di pagina, 1 GB di shared buffer richiede 262.144 voci della tabella delle pagine per ogni processo che mappa la regione. Databricks calcola che 32 GB di shared buffer distribuiti tra 512 backend possono richiedere circa 4,3 miliardi di voci.

L'azienda stima che tali voci consumerebbero circa 32 GB di tabelle delle pagine soltanto per mappare una cache da 32 GB. È un'illustrazione estrema di come un'allocazione di buffer più ampia possa spostare l'overhead altrove. Una maggiore capacità di cache non è automaticamente utile quando la gestione della memoria consuma RAM e tempo CPU eccessivi.

Il processore mantiene inoltre un translation lookaside buffer, o TLB. Questa cache hardware archivia traduzioni recenti da indirizzi virtuali a fisici. Una pagina di dati può essere presente nella memoria di Postgres mentre la CPU paga comunque una penalità per individuarla dopo un TLB miss.

Le huge page riducono questa pressione mappando la memoria in unità più grandi. Lakebase utilizza pagine HugeTLB esplicite da 2 MB per la nuova configurazione a compute fisso. Ogni huge page copre una quantità di memoria 512 volte maggiore rispetto a una pagina standard da 4 KB, riducendo dello stesso fattore il numero di voci di mappatura necessarie.

PostgreSQL espone già controlli per le huge page del sistema operativo. La sua documentazione sulle risorse spiega che le huge page esplicite possono ridurre l'overhead associato a grandi regioni contigue di memoria condivisa. Il vantaggio è particolarmente rilevante quando shared_buffers diventa molto grande.

La virtualizzazione rende l'implementazione più complessa. Lakebase esegue Postgres all'interno di macchine virtuali guest leggere su host bare-metal. La traduzione degli indirizzi attraversa quindi sia il livello guest sia quello host. Le huge page devono restare supportate in modo coerente tra host, hypervisor e guest per conservare il beneficio previsto.

Databricks afferma di aver aggiunto supporto dedicato alle huge page lungo tutto questo stack. Le grandi macchine virtuali a dimensione fissa si avviano con una quantità predeterminata di huge page. Dopo l'inizializzazione di Postgres, il sistema di compute rilascia la capacità che il database non richiede.

L'azienda ha scelto pagine HugeTLB esplicite invece delle transparent huge pages. Le transparent huge pages consentono al sistema operativo di promuovere automaticamente la memoria, ma questo comportamento segue una logica best effort. La prenotazione esplicita offre all'ambiente database un controllo più stretto sulla disponibilità e sul layout delle pagine.

Nei test di benchmark di Databricks, le huge page hanno ridotto la latenza di lettura di coda fino a circa il 40%. L'utilizzo della CPU è diminuito fino a circa il 30%. Si tratta di misurazioni aziendali, non di garanzie indipendenti per ogni carico di lavoro Lakebase.

La distinzione è importante perché le huge page non spiegano l'intero miglioramento riportato. Sono arrivati insieme due cambiamenti: più dati sono rimasti nei buffer condivisi e l'accesso a quella regione più ampia ha richiesto meno traduzioni delle pagine. I carichi di lavoro possono beneficiare di ciascun meccanismo in proporzioni diverse.

Un amministratore può verificare l'impostazione distribuita tramite Postgres. L'esecuzione di show huge_pages dovrebbe restituire on per un endpoint Lakebase idoneo da 80 unità. In combinazione con il valore di shared_buffers, questo offre un modo diretto per confermare che la nuova configurazione abbia raggiunto un compute.

Questo meccanismo spiega anche perché il semplice aumento di shared_buffers non sia una risposta completa per le distribuzioni Postgres ordinarie. La memoria riservata al database deve coesistere con connessioni, operazioni di query, processi di manutenzione e necessità del sistema operativo. Un'allocazione elevata può creare nuovi vincoli se il sistema circostante non è progettato per sostenerla.

Databricks controlla le macchine virtuali, le immagini di compute, il percorso della cache e il protocollo di storage. Questo controllo end-to-end le consente di coordinare la riserva di huge page con l'avvio di Postgres. Un team che gestisce autonomamente l'infrastruttura dovrebbe ottimizzare questi livelli separatamente e convalidare il risultato sul proprio carico di lavoro.

Il funzionamento della cache di Lakebase è quindi più complesso di “usare più RAM”. Il miglioramento dipende dal collocare i dati caldi nella giusta regione di memoria, mappare tale regione in modo efficiente e preservare memoria sufficiente per tutto ciò che si trova al di fuori del buffer pool.

I risultati in produzione mostrano miglioramenti, non una base di riferimento universale

Databricks riporta miglioramenti sostanziali da tre endpoint di produzione, ma gli esempi pubblicati non stabiliscono una media di prestazioni valida per l'intera piattaforma.

Il primo esempio ha ricevuto la nuova configurazione intorno alle 06:10 UTC dell'11 agosto. I blocchi Postgres consultati al secondo sono raddoppiati, una metrica che Databricks ha usato come indicatore del throughput. Le richieste di storage GetPage sono scese da circa 8.000 al secondo a circa 1.500.

Il cliente ha inoltre segnalato una latenza mediana e p99 inferiore rispetto al giorno, alla settimana e al mese precedenti. La release non fornisce i valori di latenza sottostanti, la definizione del carico di lavoro, il mix di query o un ambiente di confronto controllato. I lettori dovrebbero considerare l'osservazione come un risultato di produzione, non come un benchmark standardizzato.

Un secondo endpoint è cambiato intorno alle 01:30 UTC del 14 agosto. Il throughput riportato è aumentato di circa il 43%, mentre il tasso di hit della cache di compute ha sfiorato il 100%. Dopo il rollout, le richieste sono state servite quasi interamente dai buffer condivisi.

Il terzo endpoint è cambiato il 15 agosto. Databricks afferma che il consumo di CPU è sceso da 20 core a quattro, il tasso di hit della cache ha sfiorato il 100% e il throughput misurato è raddoppiato. La riduzione di cinque volte nell'uso della CPU risalta, ma il post pubblico non specifica se ogni condizione esterna del carico di lavoro sia rimasta costante.

Nel loro insieme, gli esempi supportano un meccanismo credibile. Più richieste hanno colpito la DRAM, meno letture hanno raggiunto il servizio di storage distribuito e i processori hanno dedicato meno tempo alla traduzione degli indirizzi. Questi risultati sono coerenti con le modifiche progettuali.

Non dimostrano che ogni compute idoneo diventi due volte più veloce. Databricks usa la formulazione “fino a”, e i tre risultati variano. Uno ha registrato un aumento del throughput del 43%, mentre due hanno raggiunto circa il doppio della misurazione precedente.

La composizione del carico di lavoro resta la variabile più importante. Le query sensibili alla cache, con accessi ripetuti a un set di lavoro ampio ma limitato, dovrebbero ottenere maggiori vantaggi. Operazioni con molte scritture, scansioni a basso riutilizzo, contesa sui lock, query inefficienti o logica applicativa vincolata dalla rete possono limitare il miglioramento visibile.

Anche la vecchia cache di file locale svolgeva un lavoro utile. Offriva una capacità maggiore rispetto all'allocazione originale dei buffer condivisi ed evitava molte richieste al livello di storage. Spostare le pagine calde da NVMe alla DRAM migliora il percorso più rapido, ma rimuovere quel livello secondario cambia il comportamento quando il set di lavoro supera la memoria disponibile.

Databricks afferma che, su questi compute fissi, una cache miss ora passa dai buffer condivisi allo storage distribuito. Questo solleva una domanda importante per carichi di lavoro insolitamente grandi o variabili. Un tasso di hit in memoria più elevato può coesistere con una penalità più marcata per le pagine che escono dal buffer pool ampliato.

Gli endpoint pubblicati sembrano aver tratto vantaggio perché i loro dati attivi rientravano bene nell'allocazione più ampia. Tassi di hit prossimi al 100% in due esempi suggeriscono una forte località. Applicazioni con minore località potrebbero produrre un equilibrio diverso tra hit più rapidi e miss remoti.

Anche il comportamento al riavvio merita attenzione. I buffer condivisi sono transitori, quindi un compute appena avviato normalmente inizia senza il proprio set di lavoro caldo in memoria. Databricks documenta separatamente il preriscaldamento automatico della cache, che ripopola i dati usati più frequentemente durante gli aggiornamenti pianificati.

Il preriscaldamento può ridurre la penalità della cache fredda dopo un aggiornamento, ma le applicazioni possono comunque sperimentare una breve interruzione della connessione durante il riavvio. Driver, pool e logica di retry devono gestire tale evento. I miglioramenti della cache non eliminano la necessità di resilienza delle connessioni.

Risultati di benchmark indipendenti rafforzerebbero il caso. Test utili dovrebbero rendere noti la dimensione del dataset, il numero di connessioni, la distribuzione delle query, lo stato dei buffer, la dimensione del compute e i percentili di latenza. Dovrebbero inoltre confrontare i vecchi e nuovi percorsi della cache sia con set di lavoro stabili sia variabili.

Per ora, le evidenze supportano una conclusione più circoscritta. Il miglioramento della cache di compute Lakebase Postgres sembra efficace per gli endpoint di produzione di grandi dimensioni misurati da Databricks. L'entità del beneficio per un'altra applicazione resta una questione empirica a cui gli operatori dovrebbero rispondere con le proprie metriche di latenza, tasso di hit, CPU e letture di storage.

Il conflitto principale è tra memoria fissa e autoscaling

L'attuale release migliora la metà più semplice di Lakebase, mentre la promessa serverless del prodotto dipende dal ridimensionamento della memoria cache senza riavviare Postgres.

L'impostazione shared_buffers viene normalmente scelta prima dell'avvio di Postgres. Modificarla richiede un riavvio perché il database stabilisce la propria regione di memoria condivisa durante l'inizializzazione. Questo comportamento entra direttamente in conflitto con un compute autoscaling che modifica la capacità di memoria durante l'elaborazione del traffico.

Un compute fisso evita il conflitto. Databricks conosce la quantità di memoria della macchina virtuale, ne assegna il 75% ai buffer condivisi, riserva le huge page corrispondenti e avvia Postgres. L'allocazione può restare invariata per l'intera vita della macchina.

Un endpoint autoscaling deve espandersi e ridursi. Quando la domanda aumenta, Postgres dovrebbe acquisire capacità di buffer e il guest dovrebbe ricevere la quantità esatta di huge page necessaria per mapparla in modo efficiente. Quando la domanda cala, entrambe le risorse dovrebbero essere restituite senza corrompere lo stato attivo né imporre riavvii dirompenti.

Si tratta di un compito ingegneristico sostanzialmente diverso. La memoria condivisa può contenere pagine che i backend attivi stanno leggendo, modificando, fissando o ispezionando. Ridurre la regione richiede un coordinamento sicuro con l'espulsione della cache e l'attività concorrente del database.

Databricks afferma di aver sviluppato un protocollo che ridimensiona le huge page insieme ai buffer condivisi dinamici. L'azienda prevede di spiegare questa implementazione in un secondo post tecnico. Intende inoltre collaborare con la comunità open-source PostgreSQL sulla tecnologia sottostante.

Finché quel lavoro non sarà rilasciato, Lakebase dispone di due strategie di cache. I grandi compute fissi ricevono il design con buffer condivisi ampliati. I compute autoscaling continuano a fare affidamento sulla combinazione esistente di buffer condivisi dimensionati in modo conservativo e cache di file locale.

Questa divisione mette sotto pressione il posizionamento del prodotto. La capacità fissa offre oggi il miglioramento delle prestazioni più evidente, mentre l'autoscaling offre la flessibilità associata a un database serverless. I clienti non possono ancora presumere di ricevere entrambe le caratteristiche dalla stessa modalità di compute.

Ciò non rende l'autoscaling inferiore per ogni distribuzione. Applicazioni variabili o intermittenti possono valorizzare lo scale-to-zero e la capacità elastica più della latenza di cache più bassa possibile. Un servizio di produzione stabile e ad alta intensità di memoria può preferire risorse fisse e prevedibili.

La decisione dipende anche dalla crescita del carico di lavoro. I compute fissi richiedono agli operatori di scegliere anticipatamente capacità sufficiente. L'autoscaling può assorbire le variazioni di traffico, ma l'attuale percorso della cache può instradare più hit attraverso l'NVMe locale quando il set di lavoro supera la piccola allocazione dei buffer condivisi.

Questo è il vero test competitivo per le prestazioni della cache Lakebase. Anche altri servizi Postgres gestiti combinano durabilità distribuita, caching locale, repliche e gestione elastica delle risorse. I dettagli architetturali differiscono, quindi i numeri principali dei benchmark raramente supportano una classifica chiara dei prodotti.

Databricks deve invece dimostrare che la separazione dello storage non impone una penalità evitabile ai carichi di lavoro a cui si rivolge. La disponibilità di buffer condivisi dinamici permetterebbe a Lakebase di mantenere il proprio modello di compute stateless, collocando al contempo più memoria elastica sotto il controllo diretto di Postgres.

La collaborazione upstream potrebbe estendere l'impatto oltre Lakebase. Il dimensionamento dinamico dei buffer è rilevante per gli ambienti Postgres containerizzati ed elastici, nei quali la memoria assegnata cambia nel tempo. Tuttavia, Databricks non ha ancora pubblicato il codice, lo stato della revisione o il percorso di rilascio descritti nel suo annuncio.

Questa incertezza dovrebbe restare esplicita. L'azienda ha indicato una direzione e afferma che il protocollo di autoscaling esiste. Non ha fornito una data di rilascio, l'intervallo di compute supportato o misurazioni di produzione per i buffer condivisi autoscaling.

Il rollout sui compute fissi è quindi al tempo stesso un miglioramento e un'anteprima. Convalida i meccanismi di posizionamento della cache e delle huge page in condizioni di memoria stabile. La fase successiva dovrà dimostrare che tali meccanismi possono seguire una macchina in evoluzione senza sacrificare disponibilità o prestazioni prevedibili.

Cosa dovrebbero misurare ora gli utenti Lakebase

La domanda rilevante non è se il benchmark pubblicato appaia impressionante, ma se un carico di lavoro idoneo diventi più veloce senza sviluppare una nuova penalità sui miss.

Gli utenti idonei possono anzitutto confermare la configurazione. show shared_buffers rivela l'attuale allocazione dei buffer Postgres, mentre show huge_pages indica se sono attive huge page esplicite. Un endpoint Databricks da 80 unità dovrebbe mostrare 120 GB e on, in base all'esempio dell'azienda.

La sola configurazione non stabilisce il valore. I team dovrebbero confrontare tasso di hit della cache, attività di storage GetPage, consumo della CPU, throughput e latenza delle query p50 e p99 su finestre di traffico equivalenti. Un confronto dovrebbe tenere conto di deployment, crescita dei dati, manutenzione e modifiche dell'applicazione.

Il tasso di hit della cache richiede contesto. Un tasso vicino al 100% può indicare che il set di lavoro attivo rientra in memoria. Può anche nascondere differenze nel costo delle richieste, nella frequenza delle query o nel mix di carico se viene esaminato senza throughput e latenza.

Le letture di storage forniscono un altro segnale diretto. Un calo suggerisce che più pagine restano all'interno di Postgres invece di raggiungere i pageserver. Nel suo primo esempio, Databricks ha riportato circa 5,3 volte meno richieste GetPage, in base alla diminuzione da circa 8.000 a 1.500 al secondo.

Le misurazioni della CPU possono rivelare il vantaggio delle huge page e della gestione della cache su disco evitata. Tuttavia, un minore utilizzo della CPU è più utile quando è associato a un throughput stabile o superiore. Un periodo tranquillo può ridurre sia la CPU sia il lavoro completato senza riflettere un guadagno di efficienza.

I team dovrebbero anche analizzare il comportamento durante riavvii e warm-up. Gli aggiornamenti pianificati attivano riavvii del compute, anche se Databricks afferma che in genere richiedono solo pochi secondi. Testare i tentativi di riconnessione e la latenza di coda attorno a queste finestre può rivelare effetti operativi che i grafici a regime non mostrano.

Uno scenario concreto riguarda un’applicazione transazionale i cui indici attivi e le righe consultate più di frequente occupano decine di gigabyte. Nella configurazione precedente, solo una piccola parte poteva rimanere nei buffer condivisi. Molti accessi finivano nella cache NVMe locale, nonostante la DRAM avesse capacità inutilizzata.

Dopo l’aggiornamento, quel working set potrebbe rientrare quasi interamente nel buffer pool ampliato. Il team dovrebbe aspettarsi meno richieste allo storage, minore latenza di lettura e un sovraccarico CPU ridotto. Se questi segnali non cambiano, probabilmente prevale un altro collo di bottiglia.

Un servizio di agenti AI offre un secondo scenario. Potrebbe archiviare in Postgres lo stato delle conversazioni, i risultati degli strumenti, lo stato dei job o i metadati dei vettori. Letture concorrenti e intermittenti possono trarre vantaggio dal mantenimento in memoria delle pagine riutilizzate di frequente, ma il numero di connessioni e i pattern delle query determinano comunque la pressione sui processi backend.

Gli ingegneri che valutano questo tipo di modifica hanno bisogno di evidenze condivise, non di screenshot isolati. Una base di conoscenza ingegneristica ricercabile può conservare condizioni di benchmark, piani di query, snapshot di configurazione e osservazioni sul rollout per confronti successivi.

La valutazione dovrebbe includere anche il caso di errore. Se il working set supera il buffer condiviso ampliato, i compute fissi non hanno più la precedente cache file locale come livello intermedio. Misurare la latenza durante avvii a freddo, scansioni di grandi dimensioni e cambiamenti improvvisi del working set mostrerà se i miss remoti diventano più evidenti.

Nessuno di questi controlli richiede di accettare o respingere l’affermazione principale dell’azienda. Traducono il meccanismo proposto in segnali osservabili. Se più letture colpiscono i buffer condivisi mentre CPU e latenza di coda diminuiscono a parità di domanda, l’aggiornamento sta funzionando per quel carico di lavoro.

Se il throughput rimane invariato, i team dovrebbero esaminare attese sui lock, networking dell’applicazione, piani di query, indici e pressione in scrittura prima di attribuire il risultato a Lakebase. Una modifica alla cache non può risolvere ogni fonte di latenza del database.

Tre segnali decideranno se la riprogettazione della cache conta davvero

La disponibilità dell’autoscaling, evidenze indipendenti sui carichi di lavoro e i progressi in PostgreSQL upstream determineranno se questo diventerà un vantaggio diffuso per Lakebase.

Il primo segnale è un rilascio in produzione dei buffer condivisi dinamici per i compute con autoscaling. Databricks deve dimostrare che la capacità dei buffer condivisi può crescere e ridursi insieme alla memoria, mantenendo al contempo dimensionato correttamente il supporto delle huge page. Un rilascio con criteri di idoneità, comportamento di rollout e limiti operativi dichiarati rafforzerebbe la tesi architetturale dell’azienda.

A tale rilascio dovrebbero accompagnarsi misurazioni in produzione. Il confronto utile non è quello tra autoscaling e un benchmark fisso non correlato. È lo stesso carico di lavoro elastico prima e dopo i buffer dinamici, includendo eventi di scale-up, scale-down, tassi di cache hit, utilizzo della CPU e latenza p99.

Se l’autoscaling raggiunge un’efficienza della cache comparabile senza riavvii destabilizzanti, l’analisi attuale diventa più solida. Mostrerebbe che Postgres disaggregato può combinare compute elastico con un’ampia cache di memoria gestita dal motore. Un ritardo prolungato lascerebbe il percorso più rapido confinato alla capacità fissa.

Il secondo segnale è rappresentato da evidenze di benchmark più ampie. Databricks ha pubblicato tre esempi di produzione favorevoli, ma gli utenti hanno bisogno di risultati relativi a diverse dimensioni dei working set e pattern di query. I test indipendenti dovrebbero includere transazioni a prevalenza di lettura, letture e scritture miste, alti numeri di connessioni, avvii a freddo e carichi di lavoro più grandi della DRAM disponibile.

Evidenze di miglioramenti coerenti supporterebbero il meccanismo dichiarato. Risultati molto variabili non invaliderebbero il rilascio, ma restringerebbero l’insieme delle applicazioni che probabilmente ne trarrebbero vantaggio. Una regressione nei cache miss richiederebbe maggiore attenzione dopo la rimozione del livello di disco locale.

Il terzo segnale è un progresso visibile nell’open source PostgreSQL. Databricks afferma di voler collaborare upstream sui buffer condivisi dinamici. Proposte concrete, patch, discussioni tecniche e feedback dei revisori rivelerebbero quanto della soluzione debba appartenere a Postgres stesso.

L’accettazione upstream sottoporrebbe il design a un controllo tecnico più ampio e lo renderebbe utile oltre un singolo fornitore. Potrebbe inoltre ridurre il divario a lungo termine tra gli ambienti cloud elastici e le impostazioni di Postgres progettate attorno a una macchina fissa.

Il mancato upstream del lavoro non impedirebbe a Databricks di distribuire un’implementazione specifica per la piattaforma. Renderebbe però più difficile per gli esterni valutare compatibilità, manutenzione e portabilità.

Il miglioramento della cache del compute Lakebase Postgres sta già producendo risultati misurabili su alcuni compute fissi selezionati. Il test più importante è se Databricks riuscirà a rendere dinamica la cache senza indebolire l’elasticità offerta dalla separazione dello storage.

Per i team che utilizzano endpoint idonei, il prossimo passo è semplice: verificare le impostazioni, acquisire una baseline stabile e confrontare le metriche del carico di lavoro reale dopo il rollout. Per gli utenti dell’autoscaling, occorre attendere il secondo rilascio ingegneristico prima di presumere che si applichino gli stessi vantaggi. Che cosa conta di più per la vostra applicazione oggi: le prestazioni con memoria fissa o la libertà di scalare la capacità in base alla domanda?