Database relazionale vs NoSQL: quale scegliere per la tua applicazione

Per la grande maggioranza delle applicazioni web aziendali, un database relazionale come PostgreSQL è la scelta corretta. I database NoSQL (MongoDB, Cassandra, DynamoDB) risolvono problemi specifici di scala e struttura dati che la maggior parte delle PMI non ha. Scegliere MongoDB "perché è più moderno" o "perché i dati sono in JSON" è uno degli errori architetturali più comuni e più costosi da correggere in seguito. Ma ci sono casi in cui il NoSQL è genuinamente la scelta migliore, e vale la pena conoscerli.

I database relazionali organizzano i dati in tabelle con colonne tipizzate e relazioni esplicite tra tabelle (chiavi esterne). Il modello è stato inventato negli anni '70 da Edgar Codd e non è mai stato davvero superato per i dati strutturati. Il vantaggio fondamentale è la garanzia ACID: Atomicità (ogni operazione o va tutta o non va), Consistenza (i dati rispettano sempre i vincoli definiti), Isolamento (le transazioni concorrenti non si interferiscono), Durabilità (i dati confermati sopravvivono ai crash).

PostgreSQL in particolare è diventato lo standard de facto per le applicazioni web moderne: è open source, gratuito, estremamente maturo (oltre 30 anni di sviluppo), supporta tipi di dati avanzati (JSON/JSONB, array, range, geometrie spaziali con PostGIS), ha un sistema di estensioni potentissimo, e scala verticalmente in modo molto efficiente. Il nostro team usa PostgreSQL per la quasi totalità dei progetti di sviluppo software.

NoSQL è una categoria eterogenea che include modelli molto diversi: document database (MongoDB), key-value store (Redis), column-family (Cassandra, DynamoDB), e graph database (Neo4j). Ognuno risolve un problema specifico diverso. Ciò che li accomuna è il rilassamento delle garanzie ACID in favore di scalabilità orizzontale (aggiungere server invece di potenziarne uno) e flessibilità dello schema.

Il promise del NoSQL era "scala infinita senza schema rigido" — allettante negli anni 2010 quando aziende come Twitter e Facebook avevano bisogno di gestire miliardi di utenti. Ma quella scala è irrilevante per il 99.9% delle PMI italiane. Ciò che rimane è la flessibilità dello schema, che suona bene finché non devi fare una query su dati che esistono in formati diversi in documenti diversi della stessa collection.

• Struttura dati: PostgreSQL richiede schema definito (vantaggio: consistenza garantita). MongoDB è schema-less (vantaggio: flessibilità, rischio: dati incoerenti)
• Transazioni: PostgreSQL ACID al 100% da sempre. MongoDB ha aggiunto supporto transazionale solo dalla v4.0 (2018) e con overhead significativo
• Join e query complesse: PostgreSQL eccelle — i join sono la sua ragione d'esistere. MongoDB non ha join nativi: si fa application-level join o denormalizzazione
• Scalabilità orizzontale: MongoDB scala in modo più naturale su cluster distribuiti. PostgreSQL scala verticalmente molto bene, e orizzontalmente con Citus o Neon
• JSON nativo: entrambi supportano JSON — PostgreSQL con il tipo JSONB è spesso più veloce di MongoDB per query su campi JSON indicizzati
• Maturità ecosistema: PostgreSQL ha 30+ anni, MongoDB 15+. PostgreSQL vince in stabilità e tooling
• Costo operativo: PostgreSQL gratuito e open source con ottimi managed service (Supabase, Neon, Railway). MongoDB Atlas è commerciale e può diventare costoso ad alto volume

PostgreSQL è la scelta corretta per: qualsiasi applicazione con dati strutturati e relazioni tra entità (utenti, ordini, prodotti, fatture), sistemi che richiedono garanzie transazionali forti (pagamenti, movimentazione inventario, registrazioni contabili), applicazioni che devono fare query analitiche complesse sui dati, e qualsiasi progetto dove la consistenza dei dati è critica.

In termini pratici: gestionali, CRM, portali e-commerce, SaaS B2B, piattaforme di prenotazione, sistemi HR, app finanziarie — tutti vanno su PostgreSQL. La flessibilità del tipo JSONB di PostgreSQL copre anche i casi in cui parte dei dati ha struttura variabile: puoi avere colonne tipizzate per i campi sempre presenti e una colonna JSONB per i metadati flessibili.

Redis (tecncamente un key-value store) è insostituibile come cache applicativa e per sessioni utente: le sue performance in lettura/scrittura in memoria sono ordini di grandezza superiori a qualsiasi database su disco. Lo usiamo sistematicamente in combinazione con PostgreSQL nei progetti di sviluppo web app per caching delle query frequenti e gestione delle code di job (BullMQ su Redis).

MongoDB ha senso genuino per: cataloghi di prodotti con attributi molto eterogenei (un marketplace con 50 categorie diverse dove ogni categoria ha attributi completamente diversi), content management dove la struttura dei documenti varia fortemente, e sistemi di logging e analytics dove si scrive molto e si legge raramente con query semplici. Se non sei in uno di questi casi, stai probabilmente usando MongoDB per ragioni storiche o di moda tecnologica piuttosto che per necessità tecnica reale.

L'architettura dati che usiamo nella maggior parte dei progetti complessi non è un singolo database: è una combinazione di strumenti specializzati per i diversi tipi di dato. PostgreSQL come "source of truth" per tutti i dati strutturati e transazionali. Redis come cache e message broker. Elasticsearch (o Typesense, più moderno) per la ricerca full-text avanzata. Un data warehouse (BigQuery, ClickHouse) per analytics su volumi grandi. Ogni strumento fa bene una cosa.

Questa architettura polifonica è più complessa da gestire, ma è anche più performante e più scalabile di qualsiasi approccio one-size-fits-all. La chiave è non over-engineerare all'inizio: per un MVP, PostgreSQL da solo è quasi sempre sufficiente. Si aggiungono Redis e gli altri strumenti quando i dati di utilizzo mostrano che ce n'è davvero bisogno. Se hai dubbi sull'architettura dati del tuo progetto, parlaci: è uno dei temi in cui possiamo aiutarti a fare le scelte giuste prima che diventino costose da cambiare.