07 giu 2025·8 min
Michael Stonebraker e i database moderni: cosa ha cambiato
Scopri le idee chiave di Michael Stonebraker dietro Ingres, Postgres e Vertica e come hanno modellato i database SQL, i motori analytics e gli stack dati odierni.
Scopri le idee chiave di Michael Stonebraker dietro Ingres, Postgres e Vertica e come hanno modellato i database SQL, i motori analytics e gli stack dati odierni.
Michael Stonebraker è un informatico i cui progetti non si sono solo limitati a influenzare la ricerca sui database: hanno direttamente plasmato prodotti e pattern di progettazione su cui molti team fanno affidamento ogni giorno. Se hai usato un database relazionale, un data warehouse per analytics o un sistema di streaming, hai beneficiato di idee che lui ha contribuito a dimostrare, costruire o rendere popolari.
Questo non è una biografia né un tour accademico della teoria dei database. Cerca invece di collegare i principali sistemi di Stonebraker (come Ingres, Postgres e Vertica) alle scelte che vedi negli stack dati moderni:
Un database moderno è qualsiasi sistema che può affidabilmente:
Diversi database ottimizzano questi obiettivi in modo diverso—soprattutto confrontando applicazioni transazionali, dashboard BI e pipeline in tempo reale.
Ci concentreremo sull'impatto pratico: le idee che emergono nel mondo “warehouse + lake + stream + microservices” di oggi e come influenzano cosa compri, costruisci e gestisci. Aspettati spiegazioni chiare, compromessi e implicazioni pratiche—non un tuffo profondo in dimostrazioni formali o dettagli di implementazione.
La carriera di Stonebraker è più facile da capire come una sequenza di sistemi costruiti per lavori specifici—e poi osservare le migliori idee migrare nei prodotti mainstream.
Ingres nacque come progetto accademico che dimostrò che i database relazionali potevano essere veloci e pratici, non solo teoria. Aiutò a popolarizzare le query in stile SQL e il pensiero dell'ottimizzazione basata sui costi che poi divenne normale nei motori commerciali.
Postgres (il sistema di ricerca che portò a PostgreSQL) esplorò una scommessa diversa: i database non dovrebbero essere a funzione fissa. Bisognerebbe poter aggiungere nuovi tipi di dato, nuovi metodi di indicizzazione e comportamenti più ricchi senza riscrivere l'intero motore.
Molte funzionalità “moderne” tracciano le loro origini a quest'epoca—tipi estendibili, funzioni definite dall'utente e un database che può adattarsi man mano che i carichi di lavoro cambiano.
Con la crescita dell'analisi, i sistemi orientati a righe faticavano con grandi scansioni e aggregazioni. Stonebraker promosse lo storage columnar e tecniche di esecuzione correlate mirate a leggere solo le colonne necessarie e a comprimerle efficacemente—idee ora standard nei database per analytics e nei cloud warehouse.
Vertica portò le idee della ricerca sul columnar in un motore SQL MPP (massively parallel processing) commercialmente valido, pensato per query analitiche di grandi dimensioni. Questo schema si ripete nell'industria: un prototipo di ricerca convalida un concetto; un prodotto lo rende robusto per affidabilità, strumenti e vincoli reali dei clienti.
I lavori successivi si sono estesi all'elaborazione di stream e ai motori specifici per workload—sostenendo che raramente un database generalista vince su tutto.
Un prototipo serve a testare rapidamente un'ipotesi; un prodotto deve dare priorità all'operabilità: upgrade, monitoraggio, sicurezza, prestazioni prevedibili e supporto. L'influenza di Stonebraker si vede perché molte idee da prototipo sono diventate capacità predefinite nei database commerciali piuttosto che opzioni di nicchia.
Ingres (abbreviazione di INteractive Graphics REtrieval System) fu la prova iniziale che il modello relazionale poteva essere più di una bella teoria. All'epoca, molti sistemi erano costruiti attorno a metodi di accesso personalizzati e percorsi dati specifici per le applicazioni.
Ingres cercava di risolvere un problema semplice e orientato al business:
Come permettere alle persone di fare domande flessibili sui dati senza riscrivere il software ogni volta che la domanda cambia?
I database relazionali promettevano che potevi descrivere cosa vuoi (es., “clienti in California con fatture scadute”) invece di come recuperarlo passo passo. Ma rendere reale quella promessa richiedeva un sistema che potesse:
Ingres fu un passo importante verso quella versione “pratica” del calcolo relazionale—una che potesse girare sull'hardware dell'epoca e risultare comunque reattiva.
Ingres contribuì a diffondere l'idea che il database dovrebbe fare il lavoro difficile di pianificare le query. Invece di far sì che gli sviluppatori ottimizzassero manualmente ogni percorso di accesso ai dati, il sistema poteva scegliere strategie come quale tabella leggere per prima, quali indici usare e come unire le tabelle.
Questo aiutò la mentalità SQL a diffondersi: quando puoi scrivere query dichiarative, iteri più velocemente e più persone possono fare domande direttamente—analisti, team prodotto, finanza—senza aspettare report su misura.
L'intuizione pratica è l'ottimizzazione basata sui costi: scegliere il piano di esecuzione con il costo atteso più basso (di solito una combinazione di I/O, CPU e memoria), basandosi su statistiche dei dati.
Questo importa perché spesso significa:
Ingres non inventò ogni pezzo dell'ottimizzazione moderna, ma contribuì a stabilire il modello: SQL + un ottimizzatore è ciò che fa scalare i sistemi relazionali da “bella idea” a strumento quotidiano.
I primi database relazionali tendevano a presumere un insieme fisso di tipi di dato (numeri, testo, date) e di operazioni (filter, join, aggregate). Funzionava finché le squadre non iniziarono a memorizzare nuovi tipi di informazioni (geografia, log, serie temporali, identificatori specifici di dominio) o a richiedere funzionalità di performance specializzate.
Con un design rigido, ogni nuovo requisito si traduce in scelte pessime: incastrare i dati in blob di testo, agganciare un sistema separato o aspettare che un vendor aggiunga supporto.
Postgres promosse un'idea diversa: un database dovrebbe essere estendibile—significa che puoi aggiungere nuove capacità in modo controllato, senza rompere la sicurezza e la correttezza che ti aspetti da SQL.
In parole semplici, l'estendibilità è come aggiungere accessori certificati a uno strumento elettrico invece di rimaneggiare il motore. Puoi insegnare al database “nuovi trucchi”, mantenendo transazioni, permessi e ottimizzazione delle query come un insieme coerente.
Questa mentalità si vede chiaramente nell'ecosistema moderno di PostgreSQL (e in molti sistemi ispirati a Postgres). Invece di aspettare una feature core, i team possono adottare estensioni validate che si integrano bene con SQL e con gli strumenti operativi.
Esempi ad alto livello comuni includono:
La chiave è che Postgres trattò “cambiare ciò che il database può fare” come obiettivo di progettazione—non come ripensamento—e questa idea ancora influenza come evolvono le piattaforme dati moderne.
I database non servono solo a conservare informazioni—servono a garantire che le informazioni rimangano giuste, anche quando succedono molte cose contemporaneamente. Questo è il compito delle transazioni e del controllo della concorrenza, ed è una delle ragioni principali per cui i sistemi SQL sono diventati affidabili per il lavoro di business reale.
Una transazione è un gruppo di modifiche che devono riuscire o fallire come un'unità.
Se trasferisci denaro tra conti, effettui un ordine o aggiorni l'inventario, non puoi permetterti risultati “a metà”. Una transazione garantisce che non ti ritrovi con un ordine che ha addebitato un cliente ma non ha riservato lo stock—o con scorte ridotte senza ordine registrato.
In termini pratici, le transazioni ti danno:
La concorrenza significa che molte persone (e app) leggono e modificano i dati contemporaneamente: checkout dei clienti, agenti di supporto che modificano account, job in background che aggiornano stati, analisti che eseguono report.
Senza regole attente, la concorrenza crea problemi come:
Un approccio influente è MVCC (Multi-Version Concurrency Control). Concettualmente, MVCC conserva più versioni di una riga per un breve periodo, così i lettori possono leggere uno snapshot stabile mentre gli scrittori fanno aggiornamenti.
Il grande vantaggio è che le letture non bloccano le scritture così spesso, e gli scrittori non si bloccano continuamente dietro query di lunga durata. Ottieni comunque correttezza, ma con meno attese.
I database di oggi spesso servono workload misti: scritture applicative ad alto volume insieme a letture frequenti per dashboard, viste cliente e analisi operative. I sistemi SQL moderni si basano su tecniche come MVCC, locking più intelligenti e livelli di isolamento per bilanciare velocità e correttezza—così puoi scalare l'attività senza perdere fiducia nei dati.
I database orientati a righe sono stati costruiti per l'elaborazione transazionale: molte letture e scritture piccole, di solito toccando un singolo cliente, un ordine o un account alla volta. Quel design è ottimo quando devi recuperare o aggiornare rapidamente un record intero.
Pensa a un foglio di calcolo. Un row store è come archiviare ogni riga in una propria cartella: quando ti serve “tutto su Ordine #123”, tiri fuori quella cartella ed è fatta. Un column store è come archiviare per colonna: un cassetto per “order_total”, un altro per “order_date”, un altro per “customer_region”.
Per l'analisi, raramente ti serve tutta la cartella—di solito chiedi “Qual è stato il fatturato totale per regione lo scorso trimestre?” Questa query potrebbe toccare solo pochi campi su milioni di record.
Le query analitiche spesso:
Con lo storage columnar, il motore può leggere solo le colonne referenziate nella query, saltando il resto. Meno dati letti da disco (e meno dati mossi in memoria) è spesso il guadagno prestazionale maggiore.
Le colonne tendono ad avere valori ripetitivi (regioni, stati, categorie). Questo le rende molto comprimibili—e la compressione può accelerare l'analytics perché il sistema legge meno byte e a volte opera direttamente su dati compressi in modo più efficiente.
I column store segnarono il passaggio da database orientati a OLTP verso motori orientati all'analytics, dove scansione, compressione e aggregati veloci divennero obiettivi primari piuttosto che ripensamenti.
Vertica è uno degli esempi più chiari di come le idee di Stonebraker sugli analytics siano diventate un prodotto che i team possono eseguire in produzione. Ha preso lezioni dallo storage columnar e le ha abbinate a un design distribuito pensato per un problema specifico: rispondere velocemente a grandi query SQL anche quando i volumi di dati superano un singolo server.
MPP sta per massively parallel processing. Il modo più semplice per pensarci: molte macchine lavorano contemporaneamente su una query SQL.
Invece di avere un solo server che legge tutti i dati e fa raggruppamenti e ordinamenti, i dati sono divisi tra nodi. Ogni nodo processa la propria fetta in parallelo e il sistema combina i risultati parziali in una risposta finale.
Così una query che impiegherebbe minuti su una singola macchina può scendere a secondi quando è distribuita su un cluster—a patto che i dati siano ben distribuiti e la query parallelizzabile.
I sistemi analytics in stile Vertica brillano quando hai tante righe e vuoi scansionarle, filtrarle e aggregarle efficientemente. Casi d'uso tipici includono:
I motori analytics MPP non sono un sostituto drop-in per i sistemi transazionali (OLTP). Sono ottimizzati per leggere molte righe e calcolare riepiloghi, non per gestire molti aggiornamenti piccoli.
Questo porta a compromessi comuni:
L'idea chiave è la focalizzazione: Vertica e sistemi simili guadagnano velocità ottimizzando storage, compressione ed esecuzione parallela per analytics—accettando poi i vincoli che i sistemi transazionali cercano di evitare.
Un database può “conservare e interrogare” dati e risultare comunque lento per analytics. La differenza spesso non è il SQL che scrivi, ma come il motore lo esegue: come legge le pagine, muove i dati attraverso la CPU, usa la memoria e minimizza il lavoro sprecato.
I progetti orientati all'analytics di Stonebraker hanno spinto l'idea che le prestazioni delle query sono tanto un problema di esecuzione quanto di storage. Questo ha spostato l'attenzione dall'ottimizzare lookup di singole righe all'ottimizzare lunghe scansioni, join e aggregazioni su milioni (o miliardi) di righe.
Molti motori più vecchi processano le query “tuple-at-a-time” (riga per riga), generando molte chiamate di funzione e overhead. L'esecuzione vettoriale inverte quel modello: il motore elabora un batch (un vettore) di valori in un ciclo stretto.
In termini semplici, è come spostare la spesa con un carrello invece di trasportare un oggetto per volta. Il batching riduce l'overhead e permette alle CPU moderne di fare ciò che sanno fare: loop prevedibili, meno branch e uso migliore della cache.
I motori analytics veloci sono ossessionati dall'essere efficienti in termini di CPU e cache. Le innovazioni di esecuzione si concentrano spesso su:
Queste idee contano perché le query analytics sono spesso limitate dalla banda di memoria e dai cache miss, non tanto dalla velocità grezza del disco.
I moderni data warehouse e motori SQL—warehouse cloud, sistemi MPP e strumenti analytics in-process veloci—usano frequentemente esecuzione vettoriale, operatori consapevoli della compressione e pipeline cache-friendly come pratica standard.
Anche quando i vendor pubblicizzano funzionalità come “autoscaling” o “separazione storage/compute”, la velocità che senti ogni giorno dipende ancora molto da queste scelte di esecuzione.
Se valuti piattaforme, chiedi non solo cosa conservano, ma come eseguono join e aggregati sotto il cofano—e se il loro modello di esecuzione è costruito per analytics piuttosto che per workload transazionali.
I dati in streaming sono semplicemente dati che arrivano continuamente come una sequenza di eventi—pensa a “è appena successo qualcosa” messaggi. Uno swipe di carta, una lettura di sensore, un click su una pagina prodotto, una scansione pacco, una riga di log: ognuno arriva in tempo reale e continua ad arrivare.
I database tradizionali e le pipeline batch vanno bene quando puoi aspettare: carica i dati di ieri, esegui report, pubblica dashboard. Ma le esigenze in tempo reale non aspettano il job successivo.
Se processi i dati solo a batch, finisci spesso con:
I sistemi di streaming sono progettati attorno all'idea che i calcoli possano girare continuamente man mano che gli eventi arrivano.
Una query continua è come una query SQL che non “finisce”. Invece di restituire un risultato una sola volta, aggiorna il risultato man mano che arrivano nuovi eventi.
Poiché gli stream sono illimitati (non finiscono), i sistemi streaming usano le finestre per rendere i calcoli gestibili. Una finestra è una fetta di tempo o di eventi, come “ultimi 5 minuti”, “ogni minuto” o “ultimi 1.000 eventi”. Questo ti permette di calcolare conteggi rolling, medie o top-N senza rielaborare tutto.
Lo streaming in tempo reale è più prezioso quando il timing conta:
Stonebraker ha sostenuto per decenni che i database non dovrebbero essere tutti costruiti come macchine generaliste “fai tutto”. La ragione è semplice: workload diversi premiano scelte progettuali diverse. Se ottimizzi duramente per un lavoro (ad esempio aggiornamenti transazionali piccoli), solitamente peggiori un altro lavoro (come scansionare miliardi di righe per un report).
La maggior parte degli stack moderni usa più di un sistema perché il business chiede più di un tipo di risposta:
Questo è il “one size non si adatta a tutto” nella pratica: scegli i motori che corrispondono alla forma del lavoro.
Usa questo filtro rapido quando scegli (o giustifichi) un altro sistema:
Più motori possono essere sani, ma solo quando ciascuno ha un carico di lavoro chiaro. Un nuovo strumento deve guadagnarsi il posto riducendo costo, latenza o rischio—non aggiungendo novità.
Preferisci meno sistemi con forte ownership operativa e dismetti componenti che non hanno uno scopo netto e misurabile.
I fili di ricerca di Stonebraker—fondamenti relazionali, estendibilità, column store, esecuzione MPP e “lo strumento giusto per il lavoro”—sono visibili nelle forme predefinite delle piattaforme dati moderne.
Il warehouse riflette decenni di lavoro su ottimizzazione SQL, storage columnar e esecuzione parallela. Quando vedi dashboard veloci su tabelle gigantesche, spesso stai vedendo formati columnar più elaborazione vettoriale e scaling in stile MPP.
Il lakehouse prende in prestito idee dal warehouse (schemi, statistiche, caching, ottimizzazione basata sui costi) ma le mette su formati di file aperti e object storage. Lo spostamento verso “storage economico, compute elastico” è nuovo; il pensiero sulle query e sulle transazioni sottostante non lo è.
I sistemi analytics MPP (shared-nothing cluster) discendono direttamente dalla ricerca che dimostrò che puoi scalare SQL partizionando i dati, muovendo il calcolo verso i dati e gestendo attentamente il movimento dei dati durante join e aggregazioni.
SQL è diventato l'interfaccia comune tra warehouse, motori MPP e persino livelli di query su lake. I team si affidano a esso come:
Anche quando l'esecuzione avviene in motori diversi (batch, interattivo, streaming), SQL spesso rimane il linguaggio rivolto all'utente.
Lo storage flessibile non elimina la necessità di struttura. Schemi chiari, significato documentato ed evoluzione controllata riducono i guasti a valle.
Una buona governance non è burocrazia ma rendere i dati affidabili: definizioni coerenti, ownership, controlli di qualità e controlli di accesso.
Quando valuti le piattaforme, chiediti:
Se un vendor non riesce a mappare il proprio prodotto a questi fondamentali in linguaggio semplice, l’“innovazione” potrebbe essere per lo più packaging.
Il filo conduttore di Stonebraker è semplice: i database funzionano meglio quando sono progettati per un lavoro specifico—e quando possono evolvere man mano che quel lavoro cambia.
Prima di confrontare feature, scrivi cosa devi effettivamente fare:
Una regola utile: se non riesci a descrivere il tuo workload in poche frasi (pattern di query, dimensione dei dati, esigenze di latenza, concorrenza), finirai per scegliere in base ai buzzword.
I team sottovalutano quanto spesso cambiano i requisiti: nuovi tipi di dato, nuove metriche, nuove regole di conformità, nuovi consumatori.
Favorisci piattaforme e modelli dati che rendono il cambiamento routine piuttosto che rischioso:
Risposte veloci valgono solo se sono le risposte giuste. Quando valuti opzioni, chiedi come il sistema gestisce:
Esegui una piccola “proof with your data”, non solo una demo:
Molti consigli sui database finiscono a “scegli l'engine giusto”, ma i team devono anche consegnare app e tool interni attorno a quell'engine: pannelli di amministrazione, dashboard metriche, servizi di ingestion e workflow back-office.
Se vuoi prototipare rapidamente senza reinventare tutta la pipeline, una piattaforma vibe-coding come Koder.ai può aiutarti a mettere in piedi web app (React), servizi backend (Go + PostgreSQL) e persino client mobile (Flutter) da un flusso guidato via chat. Questo è spesso utile quando stai iterando sul design dello schema, costruendo un piccolo “data product” interno o convalidando come un workload si comporta realmente prima di impegnarti in infrastrutture a lungo termine.
Se vuoi approfondire, cerca informazioni su storage columnar, MVCC, esecuzione MPP e stream processing. Altri explainer sono disponibili in /blog.
È un caso raro in cui sistemi di ricerca sono diventati parte integrante dei prodotti reali. Idee dimostrate in Ingres (SQL + ottimizzazione delle query), Postgres (estendibilità + concetti MVCC) e Vertica (columnar + analisi MPP) si ritrovano oggi nel modo in cui i data warehouse, i database OLTP e le piattaforme di streaming sono progettati e commercializzati.
SQL ha prevalso perché ti permette di descrivere cosa vuoi, mentre il database decide come ottenerlo in modo efficiente. Questa separazione ha permesso:
Un ottimizzatore basato sui costi usa statistiche di tabella per confrontare possibili piani di esecuzione e sceglie quello con il costo atteso più basso (I/O, CPU, memoria). In pratica ti aiuta a:
MVCC (Multi-Version Concurrency Control) conserva più versioni delle righe così i lettori vedono uno snapshot coerente mentre gli scrittori aggiornano. In termini pratici:
L'estendibilità permette al database di crescere con nuove capacità—tipi, funzioni, indici—senza dover forkare o riscrivere il motore. È utile quando devi:
Regola operativa: tratta le estensioni come dipendenze—versionale, testa gli upgrade e limita chi può installarle.
I row store sono ottimi quando leggi o scrivi spesso record interi (OLTP). I column store sono eccellenti quando scansiona molte righe ma tocchi pochi campi (analisi).
Una semplice euristica:
MPP (massively parallel processing) divide i dati tra nodi così molte macchine eseguono la stessa query SQL in parallelo. È adatto per:
Occhio ai compromessi: scelta della distribuzione dei dati, costi di shuffle durante i join e ergonomia peggiore per aggiornamenti frequenti di singole righe.
L'esecuzione vettoriale elabora i dati in batch (vettori) invece che riga per riga, riducendo l'overhead e sfruttando meglio le cache CPU. Di solito si traduce in:
I sistemi batch eseguono job periodici, quindi i dati “freschi” possono essere in ritardo. I sistemi di streaming trattano gli eventi come input continuo e calcolano risultati in modo incrementale.
Quando lo streaming conviene:
Per tenere i calcoli limitati, lo streaming usa le finestre (es. ultimi 5 minuti) invece di “tutto il tempo”.
Usa più sistemi quando ognuno ha un confine di workload chiaro e un beneficio misurabile (costo, latenza, affidabilità). Per evitare lo sprawl:
Se ti serve un quadro, riusa la checklist descritta nel post e nei pezzi correlati in /blog.