Cosa significa ACID in un database?

ACID è l'acronimo delle quattro garanzie che un database transazionale offre su ogni operazione: Atomicity (una transazione va a buon fine per intero o non succede nulla), Consistency (i vincoli del database restano validi prima e dopo), Isolation (transazioni concorrenti non si interferiscono) e Durability (una volta confermata, una transazione sopravvive a un crash). Sono le regole che permettono a un database di dire "questo trasferimento di denaro è avvenuto" senza ambiguità. Il termine è stato coniato negli anni '80 per descrivere le garanzie dei database relazionali come Oracle e PostgreSQL, ed è tuttora il metro con cui si valuta l'affidabilità di qualunque motore transazionale, incluse le nuove generazioni di database distribuiti che devono offrire le stesse garanzie anche quando i dati sono replicati su più nodi geografici. Senza queste quattro proprietà, un sistema può sembrare corretto nei test ma tradire l'utente proprio nei momenti critici, un crash a metà scrittura, due richieste concorrenti sullo stesso record, un guasto di rete durante il commit.

Perché i lakehouse hanno dovuto inseguirle

I database relazionali offrono garanzie ACID da decenni: senza atomicità, un pagamento potrebbe scalare da un conto senza mai accreditare l'altro; senza isolamento, due scritture concorrenti sullo stesso record potrebbero corrompersi a vicenda. I data lake tradizionali, semplici file su storage economico, non avevano niente di tutto questo: un job che si interrompeva a metà poteva lasciare i dati in uno stato incoerente, illeggibile o duplicato. I formati di tabella aperti come Delta Lake, Apache Iceberg e Apache Hudi sono nati proprio per colmare questo divario, aggiungendo un livello di transazioni, versioning e schema evolution sopra i file grezzi: è quello che ha reso possibile il data lakehouse, uno storage economico con garanzie da database.

Perché conta per la tua azienda

Se un sistema conserva dati finanziari, ordini o qualunque record dove un'incoerenza costa denaro o fiducia, verifica che le garanzie ACID siano effettivamente presenti, non solo promesse dal marketing del fornitore. Su un lakehouse moderno questo significa controllare che le tabelle usino davvero un formato transazionale (Delta, Iceberg, Hudi) e non semplici file Parquet non gestiti: la differenza si vede solo quando qualcosa va storto, un job che si blocca a metà scrittura, e a quel punto è tardi per scoprirla.