Blockchain vs database: le differenze chiave

La blockchain esiste dal 2009, e si sentono ancora i termini blockchain e database usati in modo intercambiabile, o l’affermazione che «la blockchain non è altro che un altro database». Questa impostazione causa veri errori architetturali, perché le due tecnologie rispondono a domande diverse. Un database risponde a: come memorizzo e interrogo i miei dati in modo efficiente? Una blockchain risponde a: come si accordano più parti che non si fidano l’una dell’altra su dati condivisi?

Questo articolo esamina le differenze in dettaglio, prima con una tabella comparativa di 10 righe, poi punto per punto, e si conclude con il pattern che la maggior parte dei sistemi in produzione usa davvero: un database tradizionale e una blockchain che lavorano insieme.

Cos’è una blockchain (e un «database blockchain»)

Una blockchain è un registro distribuito: un elenco di transazioni replicato su molti node indipendenti in una rete peer-to-peer. Ogni node partecipa all’amministrazione del registro. Quando devono essere aggiunti nuovi dati, la maggioranza dei node deve prima raggiungere un consenso. Questo passaggio di accordo è ciò che rende la manomissione così difficile: un attaccante dovrebbe sopraffare la maggior parte della rete, non violare un singolo server.

Ogni transazione riceve un timestamp e una posizione nella catena, così ogni node può tracciare e verificare la cronologia completa. Questa combinazione di replica e verificabilità è ciò che si intende quando si dice «database blockchain». Il termine è impreciso, perché come vedremo, una blockchain rinuncia alla maggior parte di ciò che definisce un database nel senso comune.

Cos’è un database tradizionale

Un database tradizionale usa un’architettura client-server. I client si connettono a un server centrale, e l’operatore di quel server decide chi può leggere e scrivere. L’amministratore verifica l’identità di un utente prima di concedere l’accesso e può modificare qualsiasi record in qualsiasi momento.

La centralizzazione è al contempo una debolezza e un punto di forza. Debolezza: se l’autorità centrale viene compromessa, l’intero dataset è compromesso, motivo per cui esistono i backup. Punto di forza: poiché una sola parte controlla tutto, i dati sono facili da gestire, veloci da interrogare ed economici da memorizzare. Postgres, MySQL e i loro parenti fanno funzionare praticamente ogni applicazione che usate, e si sono guadagnati questa posizione.

Blockchain vs database: 10 differenze in sintesi

Il resto dell’articolo approfondisce le righe che determinano le architetture: controllo, modello di scrittura e performance.

Controllo

La differenza più grande tra una blockchain e un database è chi comanda. In un database tradizionale, un’autorità centrale verifica e autentica gli utenti prima di concedere l’accesso. Il potere sui dati risiede in una parte, o in un piccolo gruppo.

Una blockchain non ha un’autorità del genere. Ogni node contribuisce alla gestione del registro, e i node scambiano informazioni senza un amministratore supervisore. I nuovi dati entrano nella chain solo dopo che i node raggiungono il consenso. Nessuno può riscrivere silenziosamente un record, perché tutti gli altri ne detengono una copia che dice il contrario.

Architettura

Un database tradizionale funziona su architettura client-server. Lo fa da decenni ed è bravo in questo: il modello scala da un laptop a un data center, ogni comunicazione passa attraverso una connessione al server centrale, e non esiste alcun passaggio di consenso perché la parola dell’amministratore è definitiva.

Una blockchain funziona come una rete peer-to-peer. I peer si connettono direttamente tra loro e collaborano per accordarsi sul blocco successivo tramite un algoritmo di consenso. Quello classico è Proof of Work, in cui i partecipanti spendono potenza di calcolo per validare le transazioni; Bitcoin lo usa ancora. Ethereum è passato a Proof of Stake nel 2022, che sostituisce la corsa al calcolo con garanzie economiche. In entrambi i casi, il passaggio di accordo esiste proprio perché non c’è un amministratore la cui parola potrebbe essere definitiva.

Modello di scrittura: CRUD vs solo append

Un database centralizzato supporta le quattro operazioni CRUD: create, read, update, delete. La gestione dei dati è semplice perché tutto è modificabile.

Una blockchain ne supporta due: lettura e scrittura. Una volta che una transazione è nella chain, non segue alcun update o delete. Questa immutabilità è lo scopo, poiché previene la manomissione e dà a ogni partecipante una cronologia verificabile. Ma taglia in entrambe le direzioni. Un bug che scrive dati errati non può essere corretto con un’istruzione UPDATE, e i dati personali che devono essere cancellabili su richiesta (articolo 17 del GDPR) non dovrebbero stare on-chain fin dall’inizio.

Performance e costo per scrittura

I database tradizionali sono più veloci, e non di poco. Una scrittura su database è un’operazione di disco su un’unica macchina. Una scrittura su blockchain passa per verifica della firma, consenso e replica su ogni node prima di contare. Sulle chain pubbliche questo richiede da secondi a minuti, non millisecondi.

Le scritture hanno anche un costo. Ogni transazione blockchain costa una commissione, pagata nella coin nativa della chain, e la commissione esiste per compensare i node che svolgono il lavoro di verifica. Le commissioni variano per chain e carico; su TRON, ad esempio, un trasferimento USDT costa circa 6-13 TRX a seconda dello stato dell’account del destinatario. Una scrittura su database su hardware che già possedete non costa nulla che vorreste mai contabilizzare singolarmente. Se il vostro carico è di migliaia di scritture al secondo, questo da solo risolve la questione blockchain vs database a favore del database.

Throughput e finalità in numeri

I confronti di ordine di grandezza rendono il divario concreto. I valori sotto sono volutamente approssimativi, poiché il throughput blockchain dipende dal mix di transazioni e le cifre di marketing citano regolarmente picchi teorici; tutti i valori sono aggiornati a metà 2026.

Leggete la tabella con due avvertenze. I numeri di TPS delle chain vanno decodificati: le cifre di punta di Solana includono le transazioni di voto dei validator, quindi la metrica onesta è il TPS non-vote, e i 2.000 TPS di design di TRON sono ben al di sopra delle 100-200 transazioni al secondo che la rete tipicamente sostiene nelle medie giornaliere. Le chain sono anche bersagli mobili. BSC ha ridotto il proprio block time a 0,45 secondi con l’hard fork Fermi a gennaio 2026, e l’upgrade Alpenglow di Solana, approvato con voto dei validator a settembre 2025, è pensato per portare la finalità da secondi a circa 150 millisecondi.

Nulla di tutto ciò cambia la conclusione, perché il divario non è ridotto. Un singolo server Postgres non straordinario scrive più di tutte le blockchain pubbliche esistenti messe insieme, a un costo per scrittura troppo piccolo per essere fatturato. Le chain più veloci hanno colmato il divario di latenza in modo impressionante, da minuti a uno o due secondi, ma ciascuna di quelle scritture porta comunque una commissione e un round di consenso. Le chain competono tra loro su questi numeri; non competono con i database.

ACID vs finalità del consenso

Chi lavora con i database e chi lavora con la blockchain dicono entrambi «la transazione è passata» ma intendono garanzie diverse.

In un database, le garanzie sono le proprietà ACID. Atomicità: tutte le modifiche di una transazione si applicano, o nessuna. Coerenza: i vincoli valgono prima e dopo. Isolamento: le transazioni concorrenti non vedono il lavoro a metà delle altre. Durabilità: una volta committata, la scrittura sopravvive a un crash, perché ha raggiunto il write-ahead log su disco. Tutte e quattro vengono fornite al momento del commit, millisecondi dopo la richiesta.

Una chain con smart contract si avvicina sorprendentemente alle prime tre. Una chiamata a un contract è atomica; se un passaggio va in revert, l’intera transazione va in revert. La coerenza vive nel codice del contract invece che in vincoli di schema. L’isolamento è il massimo possibile: il consenso impone a ogni transazione un unico ordine globale, che è anche esattamente il motivo per cui il throughput è limitato, poiché un ordine totale non lascia nulla da parallelizzare in sicurezza.

La durabilità è dove i modelli si separano. Una scrittura su database è durevole al commit. Una scrittura blockchain in un blocco appena creato può ancora sparire, perché blocchi concorrenti possono vincere e riorganizzare la chain. Ciò che sostituisce la durabilità è la finalità: il momento dopo il quale il protocollo garantisce che la transazione non può più essere spostata. Su TRON servono 19 blocchi, circa 57 secondi. Su Ethereum servono due epoch di attestation dei validator, 13-16 minuti; i blocchi intermedi sono probabilmente sicuri, non dimostrabilmente sicuri. La regola pratica per i sistemi di pagamento ne consegue direttamente: accreditare un cliente alla finalità, non alla prima inclusione, oppure costruire una gestione delle inversioni di cui odierete i test.

Dove si inserisce il CAP

Il teorema CAP dice che un sistema distribuito colpito da una partizione di rete deve scegliere tra restare coerente e restare disponibile. Un Postgres a singolo node elude del tutto la domanda, non essendoci nulla da partizionare, il che è un motivo sottovalutato per cui i database a singolo node restano piacevoli da gestire. I database distribuiti scelgono una parte e la documentano.

Le blockchain sono sistemi distribuiti, quindi devono scegliere anche loro. I design a catena più lunga come Bitcoin scelgono la disponibilità: durante una partizione, entrambi i lati continuano a produrre blocchi, e la coerenza viene riparata in seguito quando un ramo vince, che è esattamente cos’è un reorg. I design basati sulla finalità pendono dall’altra parte: se troppi validator sono irraggiungibili, Ethereum smette di finalizzare e i Super Representative di TRON smettono di solidificare i blocchi, sacrificando il progresso per evitare risposte permanenti in conflitto. Nessuna scelta è sbagliata. Ma significa che «blockchain» non è una via di fuga dai compromessi dei sistemi distribuiti; è un insieme specifico di quei compromessi, acquistato con latenza e commissioni.

In cosa eccelle ciascuna parte, e cosa costa

I punti di forza del database si sommano tra loro. Query in millisecondi e scritture economiche sono la parte visibile; sotto ci sono cinquant’anni di strumenti, backup e recupero point-in-time, replica, migrazioni, indici ottimizzati sui vostri pattern di query, e un mercato del lavoro pieno di persone che sanno fare tutto questo. I dati restano privati per impostazione predefinita e cancellabili su richiesta, cosa che la regolamentazione a volte richiede esplicitamente. Il costo di tutta questa comodità è la fiducia concentrata. L’operatore può modificare qualsiasi cosa, quindi una traccia di audit è credibile solo quanto lo è l’operatore, e due aziende che non si fidano l’una dell’altra non possono condividere un Postgres come fonte di verità comune senza che una lo ospiti e l’altra speri bene.

I punti di forza della blockchain sono esattamente questo pezzo mancante. Nessuno la gestisce da solo, quindi nessuno può riscriverla da solo; la cronologia è verificabile da chiunque abbia un node, inclusi esterni che non avete mai onboardato. Per i pagamenti in particolare, offre una proprietà che nessun database offre: un binario di regolamento dove qualsiasi wallet al mondo può pagarvi senza che un intermediario approvi nessuno dei due lati. I costi sono lo specchio delle comodità del database. Ogni scrittura è a pagamento e scandita dal consenso, lo storage è solo in append, tutto è pubblico a meno che non progettiate diversamente, e la rete di sicurezza operativa scompare: nessun ticket di supporto inverte una transazione, e una chiave persa è valore perso, non un reset della password.

Nessuna delle due liste vince ai punti, perché le due liste si sovrappongono a malapena. Quale conta lo decide una sola domanda: il vostro sistema ha un operatore di fiducia, o deve funzionare senza?

Quando usare cosa: una lista decisionale

• Se una sola parte controlla i dati e i suoi utenti lo accettano, usate un database. È più veloce, più economico e più facile da gestire.
• Se più parti devono scrivere in uno stato condiviso senza fidarsi l’una dell’altra o di un intermediario, una blockchain si guadagna il suo overhead. Quello è l’unico compito che i database non possono svolgere.
• Se i record devono essere dimostrabilmente inalterati per soggetti esterni (audit, regolamento tra aziende), una blockchain fornisce questo senza bisogno di un notaio.
• Se avete bisogno di aggiornamenti ed eliminazioni, o memorizzate dati personali soggetti a richieste di cancellazione, teneteli in un database.
• Se avete bisogno di bassa latenza o alto throughput di scrittura, database, senza discussione.
• Se accettate o inviate pagamenti in cripto, il livello di regolamento è una blockchain che vi piaccia o no. La mossa sensata è tenere tutto il resto off-chain, il che porta al pattern ibrido.

Tre architetture, messe alla prova

I criteri astratti diventano più chiari quando vengono applicati a sistemi concreti. Eccone tre, uno per architettura.

Un programma punti fedeltà: database puro

Un rivenditore emette punti, i clienti li riscattano alla cassa, e il team marketing aggiusta i saldi quando una promozione va storta. Ogni caratteristica di questo sistema punta nella stessa direzione. Un’azienda controlla i punti e i clienti lo accettano, quindi non c’è alcun divario di fiducia da colmare. Il volume di scrittura è di milioni di piccoli aggiornamenti al giorno, la latenza alla cassa deve restare invisibile, e i dati dell’account rientrano nelle regole di cancellazione. Postgres gestisce tutto questo senza cerimonie. Una versione on-chain pagherebbe una commissione per ogni punto accreditato, aspetterebbe il consenso alla cassa, e non potrebbe onorare nemmeno una richiesta di cancellazione GDPR. Qui tutto peggiorerebbe su una blockchain, quindi la decisione richiede circa un minuto.

Una exchange decentralizzata: puramente on-chain

Ora ribaltate ogni presupposto. Una DEX esiste affinché sconosciuti possano scambiare senza che nessun operatore detenga i loro fondi; introducete un operatore di database di fiducia e il prodotto non ha più ragione di esistere. Quindi l’intera macchina a stati — saldi, riserve del pool, logica di swap — vive nei contract, e ogni trade paga il proprio passaggio attraverso il consenso. I vincoli della chain plasmano quindi visibilmente il design: gli order book classici richiedono ordini piazzati, modificati e cancellati troppo spesso per scritture a pagamento, il che è gran parte del motivo per cui gli automated market maker hanno vinto on-chain. Gli utenti pagano commissioni e aspettano secondi per i trade perché l’assenza di fiducia è il prodotto per cui sono venuti. Notate cosa la DEX comunque non mette on-chain: il suo frontend web, gli analytics e i grafici dei prezzi girano su server e database ordinari, anche qui.

Depositi cripto per un SaaS: l’ibrido

Il caso commerciale comune si colloca tra i due estremi. Un SaaS vuole accettare USDT da clienti in tutto il mondo; i suoi abbonamenti, fatture e account utente vivono già in un database e devono restarci. La chain è inevitabile esattamente in un punto, il regolamento, e tutto il resto ne è deliberatamente tenuto lontano. Questo terzo scenario è il pattern che la maggior parte dei team finisce davvero per costruire, quindi riceve la trattazione dettagliata qui sotto.

Il pattern ibrido: database off-chain, regolamento on-chain

I sistemi di pagamento in produzione quasi mai scelgono esclusivamente l’uno o l’altro. Dividono il lavoro: la blockchain regola il valore, il database fa tutto il resto. I record dei clienti, gli ordini, i saldi e i dati di sessione vivono in Postgres o MySQL, dove sono interrogabili e modificabili. Solo il movimento effettivo dei fondi tocca la chain, tramite un’API, così che l’applicazione non gestisce mai un proprio node.

Un flusso di deposito concreto è così:

1. Un cliente vuole pagare. Il vostro backend gli assegna un indirizzo di deposito dedicato tramite chiamata API e memorizza la corrispondenza indirizzo-cliente nel vostro database.
2. Il cliente invia USDT a quell’indirizzo. Non fate polling della chain; al contrario, un webhook scatta quando il trasferimento viene confermato.
3. Il vostro endpoint verifica la firma HMAC del webhook, scrive il deposito nel vostro database, e accredita lì il saldo del cliente.

L’handler è deliberatamente poco spettacolare:

app.post("/webhooks/deposits", (req, res) => {
  if (!verifyHmacSignature(req)) return res.status(401).end();

  const tx = JSON.parse(req.body);
  db.query(
    "INSERT INTO deposits (txid, address, amount, confirmed_at) VALUES ($1, $2, $3, now())",
    [tx.txid, tx.to, tx.amount]
  );
  res.status(200).end();
});

Il payload del webhook porta txid, from, to, amount, contractaddress e blocknumber, quindi l’insert non richiede nulla oltre il corpo della richiesta. Da questo punto in poi, la logica della vostra applicazione legge i saldi dalle vostre tabelle, alla velocità e al costo di un database. La chain viene consultata di nuovo solo quando i fondi escono. I webhook di Chaingateway sono firmati HMAC; le consegne fallite compaiono sotto GET /api/v2/tron/webhooks/notifications/failed e possono essere reinviate tramite chiamata API, e le notifiche passate possono essere riottenute via GET /api/v2/tron/webhooks/notifications per la riconciliazione dopo un downtime; la guida ai webhook contiene la configurazione completa, e la quickstart copre la prima chiamata API.

Quindi chi vince?

Ciascuno è migliore in ciò che l’altro non può fare. Il database vince nettamente nella gestione dei dati: performance, scalabilità, potenza di query e costo operativo. La blockchain vince dove non esiste un operatore di fiducia: è resistente alla manomissione, verificabile da chiunque, e facile da automatizzare, poiché ogni wallet parla lo stesso protocollo.

La risposta pratica per la maggior parte dei team è entrambi, uniti da un’API: database per l’applicazione, blockchain per il regolamento. Per scegliere quel livello API, vedete il nostro confronto dei provider di API blockchain; i piani lato Chaingateway sono nella pagina prezzi.