Tipi di database - SQL, NoSQL e quando scelgo davvero ciascuno

Un «tipo di database» non è un brand. PostgreSQL e MySQL sono entrambi relazionali. MongoDB e Firestore sono entrambi archivi documentali. Redis è un motore chiave-valore che i team usano come cache, coda e a volte come deposito primario pericoloso. Scegliere un database perché un tutorial lo usava è scegliere una moda. Sceglierlo per la forma dei dati e per come l’app li interroga è architettura.

Questa è la mappa che uso quando chiedono «SQL o NoSQL?» - di solito è la prima domanda sbagliata. La prima è: cos’è una riga (o un documento, o un nodo) in questo prodotto, cosa deve restare coerente, e quali domande l’app farà mille volte al giorno?

1. Cosa significa davvero «tipo»

Tre assi contano più della categoria di marketing. Se sbagliate lì, il logo sulla scatola non vi salva.

• Modello dati: tabelle con relazioni, documenti annidati, chiavi, grafi, bucket temporali o vettori.
• Modello di query: join, filtro per campo, get-by-key, attraversamento del grafo, range nel tempo, o «cosa è vicino a questo embedding?»
• Garanzie: transazioni ACID, consistenza eventuale, semplicità di un nodo contro un cluster che sistemate alle 2 di notte.

2. Relazionale (SQL) - lo standard per soldi e relazioni

PostgreSQL, MySQL, SQLite. Righe in tabelle, chiavi esterne, join, migrazioni, transazioni ACID. Resta la casa giusta per la maggior parte dei prodotti web: utenti, spazi di lavoro, ruoli, ordini, fatture, prenotazioni, magazzino. Se una riga deve esistere perché ne esiste un’altra, o un addebito non deve accadere due volte, vi serve un motore relazionale - non un blob JSON e una preghiera.

PostgreSQL è il mio standard nel 2026: JSONB quando un campo è davvero senza schema, full-text integrato per una ricerca piccola, pgvector quando arriva il RAG. Si può crescere a lungo prima di «avere bisogno» di un secondo database. SQLite è sottovalutato per local-first, CLI e prodotti minuscoli. MySQL va bene se il team lo gira già - un progetto da zero lì non lo parto.

• Scegliete SQL quando il compito è integrità, report con join e «chi ha pagato cosa in questo spazio di lavoro».
• Non scegliete SQL perché è «enterprise». Sceglietelo perché il dominio è un grafo di fatti che devono restare veri insieme.

3. Database documentali - oggetti flessibili, relazioni costose

MongoDB, CouchDB, Firestore, DynamoDB in modalità document. Un documento è un albero JSON. Sta bene quando l’unità di lavoro è un oggetto con pezzi annidati che caricate sempre insieme: un articolo CMS, un prodotto con un sacco di attributi, un profilo utente che prendete sempre intero.

La trappola: avete comunque utenti, spazi di lavoro e fatture. Reinventerete i join nell’app, perderete le transazioni multi-documento (o le pagherete) e passerete un anno ad aggiungere regole di unicità che un motore relazionale vi avrebbe dato il giorno uno. Uso un archivio documentale quando il prodotto ha forma di contenuto e il pattern è «carica questo blob per id». Non perché il frontend parla JSON. Postgres JSONB parla già JSON.

4. Chiave-valore - Redis e compagnia

Redis, Memcached, DynamoDB come deposito chiave-valore puro. Get, set, expire. Liste, set, pub/sub opzionali. Qui non vive il sistema di record. È lo strato veloce accanto.

• Bene: sessioni, limiti di ritmo, flag di funzionalità, chiavi di idempotenza, cache di letture care, blocchi brevi.
• Male: l’unica copia di ordini, utenti o permessi. Un flush o una policy di eviction - e avete un incubo di supporto.

5. Wide-column - quando le scritture non si fermano

Cassandra, Scylla, Bigtable. Partizionate per chiave, scrivete tanto, leggete per quella chiave, e accettate che l’SQL ad hoc non è il punto. Giusto per telemetria a scala enorme, feed tipo casella, carichi molto in scrittura multi-regione. Sbagliato per un SaaS di prenotazione con dodici tabelle. Se non avete già un numero tipo «milioni di scritture al secondo», saltate la categoria. Il costo operativo del cluster è il prodotto.

6. Grafo - quando la domanda è la connessione

Neo4j, Amazon Neptune e - per grafi piccoli - SQL con CTE ricorsive. Un motore a grafo quando il prodotto è la rete: raccomandazioni, anelli di frode, organigrammi, ereditarietà dei permessi, «chi è a due salti da questo fornitore». Non perché avete disegnato scatole e frecce sulla lavagna. Quasi ogni dominio ha relazioni. I database relazionali le modellano già. I motori a grafo si guadagnano il posto quando la profondità dell’attraversamento è la query, non il diagramma dello schema.

7. Time-series - metriche, sensori, eventi nel tempo

InfluxDB, TimescaleDB, Prometheus per ops, ClickHouse per eventi a forma di analytics. Se ogni riga è «questo device o metrica a questo timestamp», uno schema OLTP generale fa male: troppi insert, range scan, retention. TimescaleDB attrae perché resta PostgreSQL: stessi backup, stesso SQL, hypertables per il percorso caldo. ClickHouse è analytics, non la transazione di cassa. Non scaricate la tabella ordini in un motore time-series solo perché esiste created_at.

8. Vettore - embedding, non una seconda fonte di riferimento

Pinecone, Qdrant, Weaviate e pgvector in Postgres. Si memorizzano vettori per chiedere «quale testo è vicino a questa domanda?» È RAG, ricerca semantica, rilevamento duplicati. L’articolo, il prezzo, l’utente vivono ancora nel database operativo. L’indice vettoriale è un indice derivato, come la ricerca. Ricostruirlo. Non fate dipendere cassa o permessi da lui.

Nel 2026 aggiungo prima pgvector a Postgres. Un database vettoriale dedicato quando dimensione del corpus e QPS giustificano un altro pezzo mobile - non perché un pitch deck ha detto «AI-native».

9. La ricerca non è un database di record

Elasticsearch, OpenSearch, Typesense, Meilisearch. Full-text, tolleranza ai typo, faccette, ranking. Ricostruire dalla fonte di riferimento. Non fate mai dipendere cassa, magazzino o permessi solo da un indice che può divergere dopo un reindex fallito. Il full-text di Postgres basta a molti cataloghi piccoli. Aggiungete un motore di ricerca quando gli utenti digitano query sporche e vi serve rilevanza - non quando vi siete stancati di SQL.

10. Come scelgo davvero

Faccio girare i filtri in quest’ordine. La stack arriva dopo le risposte, non prima della tabella di confronto.

• Qual è l’unità di coerenza? Se si muovono soldi o magazzino: SQL con transazioni. Non «i doppi li sistemiamo nell’app».
• Qual è la query calda? Per id, join, full-text, similarità, range temporale o salto di grafo? Agganciare il motore a quella forma.
• Chi lo opera alle 2 di notte? Un Postgres gestito batte un cluster furbo che nessuno nel team sa sistemare.
• Un motore copre l’80%? Postgres più Redis coprono la maggior parte dei prodotti web che metto davvero in produzione.

Uno standard 2026 da cui partirei davvero

Finché il modello dati non forza uno specialista dal giorno uno, aprirei con questa stack - e rifiuterei di allargarla finché non compare un collo misurato, non un post del blog.

• PostgreSQL come fonte di riferimento. JSONB dove un campo è davvero senza schema. pgvector se il RAG è una funzione vera, non una slide.
• Redis per cache, sessioni, limiti di ritmo e code leggere. Non per gli ordini.
• Object storage per i file. Un motore di ricerca solo quando LIKE e il FTS di Postgres non bastano.

Il tipo è la forma del compito

SQL contro NoSQL era un dibattito degli anni 2010. La domanda utile nel 2026: quale modello dati sta al compito, e quanti pochi sistemi sapete operare bene. Partite da una fonte di riferimento relazionale. Aggiungete un deposito specialista quando la forma della query è davvero diversa - cache, ricerca, vettori, time-series. L’ibrido è normale. Cinque database il giorno uno di un MVP è come muore l’esperimento.