UUID vs ID autoincrementale: quale usare nel tuo database

Una delle decisioni più importanti nella progettazione di un database è la scelta della chiave primaria. Le due opzioni principali sono ID autoincrementali (1, 2, 3...) e UUID (stringhe univoche come 550e8400-e29b-41d4-a716-446655440000). Vediamo pro e contro di ciascuno.

ID autoincrementali: semplici e compatti

Sono il default di MySQL, PostgreSQL, SQLite. Il database assegna automaticamente il prossimo numero.

• Pro: compatti (4 o 8 byte), veloci da indicizzare, leggibili, occupano meno spazio.
• Contro: rivelano il numero di record (concorrenza!), non sicuri in URL pubblici (es. /order/42 rivela che hai 42 ordini), difficili da sincronizzare tra database distribuiti.

UUID: univoci senza coordinazione

Gli UUID sono stringhe di 128 bit generate localmente, senza bisogno di un'autorità centrale. Anche due server che generano UUID contemporaneamente non avranno collisioni.

• Pro: univoci senza coordinazione, sicuri in URL pubblici, ideali per sistemi distribuiti, microservizi e sincronizzazione offline-first.
• Contro: più grandi (16 byte o 36 caratteri), meno efficienti in indice (random order = index fragmentation), meno leggibili per debugging.

UUID v4 vs v7: una differenza importante

UUID v4 è completamente random: perfetto per unicità ma pessimo per indici B-tree (ogni insert va in posizione casuale dell'indice = fragmentation).

UUID v7, introdotto recentemente, include un timestamp Unix nei primi 48 bit. Risultato: UUID generati in momenti vicini sono anche vicini nell'ordinamento. Questo risolve il problema della fragmentation dell'indice, rendendoli quasi efficienti quanto gli autoincrement, mantenendo il vantaggio dell'unicità distribuita.

Quando usare cosa

• App monolitica semplice, single-DB: autoincrement va benissimo.
• API pubblica dove l'ID è visibile in URL: UUID (evita enumeration attack).
• Microservizi / multi-DB / offline-first: UUID obbligatorio.
• Sistemi nuovi ad alto traffico: UUID v7 (unicità + buone performance di indice).
• Sistemi legacy ad alto traffico: mantieni autoincrement, non migrare solo per moda.

In breve

Per la maggior parte dei progetti nuovi, UUID v7 è la scelta più bilanciata: univoco, distribuito, e con performance di indicizzazione accettabili. Per sistemi semplici e locali, l'autoincrement resta un'ottima scelta, più compatta ed efficiente.