PostgreSQL vs MongoDB nel 2026: quando scegliere cosa, con esempi concreti

Il problema vero non è il database, è la domanda sbagliata

Ogni anno almeno un cliente ci arriva con la stessa storia: hanno scelto MongoDB perché "è più flessibile", oppure PostgreSQL perché "è quello che conoscevamo". Sei mesi dopo stanno riscrivendo query aggregazione da zero o cercando di imporre uno schema rigido su una collezione che nel frattempo è diventata un campo minato di campi opzionali.

Nel 2026 entrambi i database sono maturi, scalabili e supportati da ecosistemi solidi. La scelta sbagliata non ti uccide — ma ti costa. In tempo di sviluppo, in complessità operativa, in debito tecnico.

Quindi: come si decide?

---

Le differenze che contano davvero

Modello dati

PostgreSQL è relazionale. I dati hanno uno schema dichiarato, le relazioni sono esplicite, i vincoli di integrità sono enforced dal motore. Questo non è un limite: è una garanzia.

MongoDB è document-oriented. Ogni documento è un JSON arbitrario. Non esiste uno schema obbligatorio a livello di motore (anche se dal 2019 esiste la validazione JSON Schema opzionale). La flessibilità è reale, ma ha un prezzo: la coerenza del dato diventa responsabilità dell'applicazione.

Pattern di accesso

La domanda da farsi è: come leggeranno i dati le tue query?

Hai relazioni molti-a-molti complesse? Join multipli, aggregazioni su tabelle diverse? → PostgreSQL.
I tuoi dati sono gerarchici e tendono a essere letti e scritti insieme come unità? → MongoDB.
Hai bisogno di transazioni ACID su più entità? → PostgreSQL (MongoDB supporta le transazioni multi-documento dal 4.0, ma con overhead non trascurabile).
Il tuo schema cambia frequentemente per ragioni di prodotto, non di bug? → MongoDB vale la pena di considerarlo.

Esempio concreto: e-commerce

Immagina un catalogo prodotti con varianti, attributi dinamici per categoria (scarpe → taglia/colore, elettronica → voltaggio/frequenza) e prezzi per mercato.

Con PostgreSQL:

CREATE TABLE products (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  category_id INT REFERENCES categories(id)
);

CREATE TABLE product_attributes (
  product_id UUID REFERENCES products(id),
  key TEXT NOT NULL,
  value TEXT NOT NULL,
  PRIMARY KEY (product_id, key)
);

Funziona, ma le query per recuperare un prodotto con tutti i suoi attributi diventano join + pivot. Non impossibile, ma verboso.

Alternativamente, PostgreSQL supporta JSONB:

CREATE TABLE products (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  category TEXT NOT NULL,
  attributes JSONB
);

-- Indice su un campo JSON annidato
CREATE INDEX idx_products_color
  ON products ((attributes->>'color'));

-- Query
SELECT name, attributes->>'color' AS color
FROM products
WHERE category = 'shoes'
  AND attributes->>'size' = '42';

JSONB in PostgreSQL copre molti dei casi d'uso per cui si sceglie MongoDB, senza abbandonare il modello relazionale per il resto del sistema.

Con MongoDB:

// Documento prodotto
{
  _id: ObjectId("..."),
  name: "Sneaker X",
  category: "shoes",
  attributes: { color: "white", size: "42" },
  prices: [
    { market: "IT", amount: 89.99, currency: "EUR" },
    { market: "US", amount: 95.00, currency: "USD" }
  ]
}

// Query
db.products.find(
  { category: "shoes", "attributes.size": "42" },
  { name: 1, "attributes.color": 1 }
);

La lettura è semplice e il documento è auto-contenuto. Ma se devi fare un report che incrocia prodotti, ordini e clienti, stai per scoprire $lookup — e non è piacevole quanto un JOIN dichiarativo.

---

Quando PostgreSQL è la risposta ovvia

Dati finanziari o transazionali. Le transazioni ACID di PostgreSQL sono battle-tested. Se stai gestendo movimenti contabili, ordini, pagamenti: non c'è dibattito.
Reporting e analytics interni. Window functions, CTE ricorsive, GROUPING SETS: PostgreSQL è un motore analitico serio senza bisogno di strumenti aggiuntivi.
Team con esperienza SQL consolidata. Il costo di onboarding su un ORM + schema migrations è noto e gestibile.
Sistemi con relazioni complesse tra entità. Utenti, ruoli, permessi, organizzazioni, asset: il modello relazionale rende questi vincoli espliciti e verificabili.

Quando MongoDB ha senso

Dati gerarchici con struttura variabile. CMS, cataloghi con attributi fortemente eterogenei, configurazioni di tenant diverse per struttura.
Ingestione rapida di dati semi-strutturati. Log applicativi, eventi IoT, feed di terze parti con schema non controllato.
Prototipi in cui lo schema evolve ogni sprint. MongoDB permette di iterare senza migration, ma attenzione: questa libertà va disciplinata prima di andare in produzione.
Sharding orizzontale nativo. Per volumi molto elevati con pattern di accesso ben definiti, il sharding di MongoDB è più semplice da configurare rispetto alle soluzioni equivalenti su PostgreSQL (Citus, partitioning nativo).

---

L'opzione ibrida: non è un compromesso, è architettura

In sistemi complessi, usare entrambi non è un segno di indecisione. È una scelta consapevole.

Un pattern comune nei sistemi che seguiamo:

PostgreSQL per il core transazionale: utenti, ordini, fatture, ACL.
MongoDB per i dati di contesto variabile: preferenze utente, payload di eventi, storico attività con schema eterogeneo.
Redis per cache e rate limiting.

L'importante è che il confine tra i due sia esplicito nel design e documentato. Il problema non è usare due database — è non sapere perché li stai usando entrambi.

---

Take-away operativo

Prima di scegliere, rispondi a queste domande:

I miei dati hanno relazioni forti tra entità diverse? → PostgreSQL.
I documenti sono letti e scritti come unità autonome, raramente in join? → MongoDB.
Ho bisogno di transazioni ACID cross-entità? → PostgreSQL (o MongoDB 6+ con attenzione ai costi).
Il mio schema è instabile per ragioni legittime di prodotto? → MongoDB, ma con validazione JSON Schema attiva.
Ho già JSONB in PostgreSQL e risolve il problema? → Non aggiungere un secondo database per moda.

La regola pratica: PostgreSQL è il default sicuro. MongoDB è la scelta consapevole per casi specifici. Non il contrario.

---

Evviva Group affianca team di sviluppo B2B nella scelta e nel setup di architetture dati. Se stai valutando una migrazione o una nuova architettura, possiamo aiutarti a valutare i trade-off prima di scrivere una riga di codice.