MongoDB vs PostgreSQL: scegliere il database giusto nel 2026

Come ragionare su questo confronto

Scegli PostgreSQL quando nel carico di lavoro prevalgono relazioni, vincoli, transazioni e report flessibili. Scegli MongoDB quando la maggior parte delle operazioni legge o aggiorna documenti autosufficienti, di dimensione limitata e con campi molto variabili. Nessuno dei due motori è sempre più veloce o più semplice.

Parti dall'applicazione, non da una lista di funzioni. Un sistema di fatturazione ha condizioni di errore diverse da un catalogo di contenuti, anche se entrambi espongono JSON tramite API. Il database dovrebbe rendere normali le operazioni più difficili dell'applicazione, non soltanto possibili.

Valuta entrambe le opzioni con cinque domande concrete:

• Quali record devono cambiare insieme nella stessa transazione?
• Quali query attraversano i confini tra entità e quanto spesso cambiano?
• Quali regole devono restare vere anche se il codice dell'applicazione fallisce?
• Quanto può crescere un singolo record logico e la sua raccolta di elementi figli può crescere senza limiti?
• Chi gestirà il database, lo ripristinerà, lo ottimizzerà e risponderà agli incidenti?

PostgreSQL è in genere la scelta meno rischiosa per account SaaS, autorizzazioni, ordini, fatturazione, inventario, audit trail, CRM ed ERP. Questi domini contengono molte relazioni molti-a-molti e invarianti che si adattano a tabelle, chiavi esterne, vincoli univoci e SQL.

MongoDB si adatta spesso a contenuti, prodotti con attributi specifici per cliente, documenti di configurazione, payload di eventi e altri aggregati recuperati normalmente come un unico oggetto. La sua struttura flessibile può velocizzare la prima implementazione, purché il team continui a governare l'evoluzione dello schema.

Usare entrambi i database è ragionevole quando ciascuno possiede un dominio chiaramente separato. Diventa costoso quando il confine è vago: significa due sistemi di backup, due modelli di monitoraggio, due configurazioni di sicurezza e un meccanismo di sincronizzazione. Accetta questo costo solo se un database imporrebbe un problema persistente di modellazione o scalabilità.

Modello dati: documenti o tabelle relazionali

MongoDB si adatta a dati memorizzabili come aggregati limitati, PostgreSQL a dati il cui valore dipende dalle relazioni tra entità che cambiano in modo indipendente. La differenza va oltre JSON contro righe, perché determina dove risiedono le regole di coerenza.

Un ordine MongoDB può incorporare indirizzo di spedizione e righe d'ordine:

{
  "_id": "order_1042",
  "customerId": "customer_28",
  "status": "paid",
  "shippingAddress": {
    "city": "Austin",
    "country": "US"
  },
  "items": [
    { "productId": "product_7", "quantity": 2, "unitPrice": 19.95 }
  ]
}

Una ricerca indicizzata può restituire l'ordine completo e un singolo aggiornamento può modificare atomicamente l'ordine e gli elementi incorporati. È utile quando queste parti condividono il ciclo di vita e l'array resta limitato.

Il modello PostgreSQL equivalente separa fatti con significato indipendente:

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint NOT NULL REFERENCES customers(id),
    status text NOT NULL,
    placed_at timestamptz NOT NULL
);

CREATE TABLE order_items (
    order_id bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12, 2) NOT NULL CHECK (unit_price >= 0),
    PRIMARY KEY (order_id, product_id)
);

Questo modello rende diretti i report tra ordini e relazioni con i prodotti. Il database può rifiutare un elemento il cui ordine o prodotto non esiste e permette a un prodotto di cambiare indipendentemente, mantenendo il prezzo registrato al momento dell'acquisto.

L'incorporamento non è adatto a raccolte senza limite, come tutti gli eventi generati da un account. Un documento in continua crescita diventa un punto caldo di scrittura, consuma più banda e prima o poi raggiunge il limite MongoDB di 16 MiB per documento. In questi casi conserva gli eventi come documenti separati.

Anche la normalizzazione può essere eccessiva. Dividere un piccolo oggetto valore tra molte tabelle aggiunge join senza creare autonomia utile. L'indirizzo di spedizione di un ordine completato è spesso un'istantanea storica, non un riferimento attivo all'indirizzo attuale del cliente.

Una regola durevole è incorporare dati che cambiano insieme e restano limitati. Riferisci o normalizza dati che cambiano in modo indipendente, partecipano a molte relazioni o crescono senza un limite prevedibile.

Evoluzione dello schema e integrità dei dati

MongoDB semplifica l'aggiunta di campi, PostgreSQL rende più semplice imporre una struttura uniforme. La sicurezza in produzione dipende da migrazioni disciplinate in entrambi i sistemi.

Le raccolte MongoDB possono contenere documenti con campi e tipi diversi. Questa flessibilità aiuta quando gli attributi variano per cliente o tipo di contenuto, ma può creare versioni incompatibili dello stesso concetto. Un campo rinominato può lasciare vecchi documenti e costringere ogni lettore a gestire alternative.

MongoDB supporta la validazione delle raccolte con regole in stile JSON Schema. Il team può introdurla gradualmente, aggiornare i documenti esistenti e poi rifiutare le nuove scritture che violano la forma scelta. Un campo di versione dello schema può aiutare i worker a migrare in modo prevedibile i documenti vecchi, ma non sostituisce la validazione.

In PostgreSQL le modifiche sono esplicite. Di norma si aggiunge una colonna nullable, si pubblica codice che quando serve scrive sia il formato vecchio sia il nuovo, si aggiorna i dati in batch controllati, si convalida e poi si aggiungono vincoli più stretti. Gli indici grandi possono essere creati in modo concorrente per ridurre le interruzioni delle scritture.

Gli invarianti utili devono stare nel database quando il motore può esprimerli:

• Usa vincoli univoci per identificatori, token di idempotenza e record uno-per-proprietario.
• Usa chiavi esterne per relazioni che non devono mai puntare a dati mancanti.
• Usa vincoli CHECK per regole locali, come quantità positive.
• Usa la validazione applicativa per regole contestuali che richiedono servizi remoti o policy che cambiano spesso.
• Usa test per verificare il percorso di migrazione da ogni versione di schema supportata.

La validazione applicativa resta necessaria per messaggi d'errore chiari e flussi aziendali. I vincoli del database sono la barriera finale contro condizioni di gara, percorsi di codice dimenticati, script amministrativi e servizi futuri che scrivono gli stessi dati.

Uno schema flessibile dovrebbe significare variazioni controllate, non variazioni sconosciute. Prima di scegliere MongoDB per iterare più velocemente, definisci chi possiede la forma dei documenti, come vengono rilevate le modifiche incompatibili e quando i documenti vecchi vengono riscritti.

Query, join e reportistica

PostgreSQL è più diretto per domande variabili su più entità, mentre MongoDB è conciso quando una query segue il confine di un documento. L'ergonomia delle query diventa sempre più importante quando il prodotto accumula requisiti di reporting.

SQL è dichiarativo. Filtri, join, raggruppamenti, espressioni comuni di tabella, funzioni finestra, sottoquery e operazioni tra insiemi si combinano senza cambiare il modello memorizzato. Il planner di PostgreSQL sceglie algoritmi di join e percorsi di accesso in base alle statistiche e agli indici disponibili.

Una query sui ricavi su dati degli ordini normalizzati resta leggibile:

SELECT
    o.customer_id,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.status = 'paid'
  AND o.placed_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;

MongoDB usa operazioni find dirette per il recupero semplice e una pipeline di aggregazione per le trasformazioni. Con righe d'ordine incorporate, il calcolo equivalente elabora documenti in fasi ordinate:

db.orders.aggregate([
  { $match: { status: "paid", placedAt: { $gte: startDate } } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$customerId",
      revenue: { $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] } }
    }
  },
  { $sort: { revenue: -1 } }
])

La pipeline è potente, ma l'ordine delle fasi modifica significato e consumo di risorse. Array grandi possono moltiplicare l'insieme di lavoro dopo $unwind; filtrare e proiettare presto può ridurre il costo.

$lookup di MongoDB unisce documenti di un'altra raccolta. È utile per relazioni selezionate, soprattutto quando il lato unito è indicizzato e il risultato resta piccolo. Un modello che richiede molti $lookup nelle richieste comuni segnala che i suoi confini potrebbero essere relazionali.

PostgreSQL è in genere più semplice per business intelligence, report finanziari, analisi di coorti e domande non pianificate, perché la maggior parte degli strumenti di reportistica parla SQL. Il reporting MongoDB funziona bene quando le dimensioni sono già insieme o un modello di lettura preparato coincide con il report. I team che svolgono molte analisi estemporanee spesso esportano comunque i dati operativi in un data warehouse.

Il mapping a oggetti non elimina questi compromessi. Un ORM può far sembrare oggetti le righe PostgreSQL e un object document mapper può imporre classi ai documenti MongoDB. Relazioni, indici e regole di integrità memorizzati determinano comunque il comportamento sotto carico.

Transazioni e concorrenza

PostgreSQL offre il modello più naturale per transazioni su più righe e tabelle. MongoDB offre il confine atomico meno costoso per modifiche a un singolo documento e supporta transazioni più ampie quando servono. La scelta corretta segue gli invarianti che devono sopravvivere a richieste concorrenti.

PostgreSQL usa il controllo di concorrenza multiversione. Letture e scritture ordinarie possono procedere insieme, anche se blocchi di riga, blocchi espliciti, transazioni lunghe e modifiche allo schema possono creare attese. Read Committed è il livello di isolamento predefinito; Repeatable Read fornisce un'istantanea stabile e Serializable rileva esecuzioni che non possono essere ordinate in sicurezza.

Le operazioni MongoDB che modificano un documento sono atomiche. Incorporare un aggregato limitato riduce quindi il coordinamento. MongoDB supporta anche transazioni ACID su più documenti in replica set e cluster sharded. Queste transazioni aggiungono coordinamento, trattengono risorse e possono produrre errori transitori che richiedono di ritentare l'intera transazione.

MongoDB espone separatamente read concern, write concern e read preference. Queste impostazioni determinano quali dati può osservare una lettura, quanti membri del replica set devono confermare una scrittura e se le letture possono andare alle secondarie. Considerale prima impostazioni di correttezza e poi controlli di latenza.

Nessuno dei due database può includere un fornitore esterno di pagamenti in una transazione locale. Mantenere aperta una transazione durante una richiesta di rete aumenta la contesa e non rende atomico il commit dei due sistemi. Un flusso più sicuro registra un ordine in attesa e un evento outbox nella stessa transazione, elabora la richiesta esterna in modo idempotente e poi registra il risultato.

I test di concorrenza devono colpire le gare aziendali, non solo le richieste riuscite: due acquirenti che prenotano l'ultimo articolo, due worker che rivendicano lo stesso lavoro o due amministratori che assegnano lo stesso nome univoco. PostgreSQL può spesso esprimere queste operazioni con vincoli, blocchi di riga o istruzioni atomiche. MongoDB può usare aggiornamenti condizionali, indici univoci e transazioni.

Se regole rigorose attraversano molti record memorizzati indipendentemente, PostgreSQL richiede di solito meno coordinamento applicativo. Se ogni regola rientra in un documento ben progettato, le operazioni atomiche sui documenti MongoDB sono semplici ed efficaci.

PostgreSQL JSONB come soluzione intermedia

PostgreSQL JSONB è una buona scelta quando campi relazionali stabili circondano un insieme limitato di attributi in evoluzione. Non trasforma ogni problema a documenti in un problema relazionale, ma può eliminare la necessità di un secondo database.

Un modello comune conserva identità, proprietà, stato e timestamp in colonne tipizzate e mette gli attributi facoltativi in jsonb. Le chiavi esterne proteggono le relazioni, gli indici ordinari supportano filtri frequenti e gli indici GIN o di espressione accelerano predicati JSON selezionati.

CREATE TABLE products (
    id bigint PRIMARY KEY,
    account_id bigint NOT NULL REFERENCES accounts(id),
    sku text NOT NULL,
    status text NOT NULL,
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb,
    UNIQUE (account_id, sku)
);

CREATE INDEX products_attributes_gin
    ON products USING gin (attributes);

Funziona per attributi di catalogo come materiale, dimensioni o metadati regionali che differiscono tra tipi di prodotto. È meno adatto quando ogni campo importante è nascosto nel JSON e ogni query richiede conversioni, espressioni di percorso o validazione personalizzata.

JSONB conserva una rappresentazione binaria analizzata, supporta operatori di contenimento e elimina formattazioni irrilevanti, come l'ordine delle proprietà di un oggetto. Conserva inoltre un solo valore per una proprietà duplicata. Le applicazioni che devono riprodurre esattamente il testo JSON originale dovrebbero conservarlo separatamente.

L'aggiornamento di una piccola proprietà crea una nuova versione della riga PostgreSQL e può riscrivere un valore JSONB considerevole. Documenti grandi e aggiornati spesso possono quindi generare molto write-ahead log e tuple morte. Separare i campi più attivi in colonne o tabelle figlie spesso offre prestazioni migliori.

Le chiavi esterne non possono imporre direttamente relazioni nascoste in JSON arbitrario. Promuovi a colonne i valori interrogati, uniti, ordinati o vincolati spesso. Colonne generate e indici di espressione aiutano durante una transizione graduale, ma un campo relazionale è di solito più chiaro quando il suo significato si stabilizza.

Indici e piani di query

Entrambi i database dipendono da indici che corrispondono a filtri, ordinamenti e cardinalità reali. Indicizzare indiscriminatamente rallenta le scritture e consuma memoria. I motori offrono strumenti diversi, ma nessuno può salvare un modello di accesso in conflitto con il modello memorizzato.

PostgreSQL usa indici B-tree per uguaglianza, intervalli e recupero ordinato. Gli indici GIN supportano contenimento JSONB, array e ricerca full-text. GiST e SP-GiST coprono varie classi di operatori geometrici, di intervallo e specializzati. BRIN è una scelta compatta per tabelle molto grandi il cui ordine fisico è correlato a un valore, come il tempo.

PostgreSQL supporta anche indici parziali e di espressione. Un indice parziale sugli abbonamenti attivi può essere molto più piccolo di uno che copre anni di record inattivi. Un indice di espressione può supportare un indirizzo email normalizzato o una proprietà JSON selezionata.

MongoDB indicizza direttamente proprietà annidate e array. Un indice multikey espande i valori dell'array in voci di indice: rende efficienti le query di appartenenza, ma può far crescere rapidamente l'indice. Un indice composto multikey non può indicizzare più di un campo con valori array nello stesso documento. MongoDB offre anche indici geospaziali, hashed, wildcard, parziali, sparse e TTL per i rispettivi modelli di accesso.

L'ordine delle colonne negli indici composti segue la struttura della query, non una regola universale del campo più selettivo per primo. In un B-tree multicolonna PostgreSQL, condizioni di uguaglianza sulle colonne iniziali e un intervallo su quella successiva spesso consentono una scansione efficiente. In MongoDB si parte spesso da campi di uguaglianza, poi ordinamento e intervallo, verificando però se un ordine alternativo esamina meno voci nella distribuzione reale.

Usa i piani di query invece delle supposizioni:

• In PostgreSQL esegui EXPLAIN (ANALYZE, BUFFERS) su letture rappresentative e controlla stime delle righe, cicli, ordinamenti, passaggi su disco e attività dei buffer.
• Ricorda che ANALYZE esegue l'istruzione, quindi fai attenzione a scritture e traffico di produzione.
• In MongoDB richiedi statistiche di esecuzione e confronta documenti esaminati, voci di indice esaminate e risultati restituiti.
• Prova valori di parametro comuni e valori sbilanciati che corrispondono a una grande quota dei dati.
• Rimuovi indici inutilizzati solo dopo aver verificato che non servano a carichi periodici, amministrativi o di failover.

Un indice che copre perfettamente un endpoint può duplicarne un altro o aumentare il lavoro di ogni scrittura. Valuta l'insieme completo degli indici come un portafoglio, non approvando ciascuno in isolamento.

Ricerca, geospaziale e serie temporali

Entrambi i database coprono ricerche di base, localizzazione e query temporali, ma requisiti specializzati possono giustificare strumenti separati o funzionalità gestite. La scelta deve seguire qualità della pertinenza, tasso di ingestione, conservazione e responsabilità operativa.

La ricerca full-text di PostgreSQL offre tokenizzazione, dizionari, vettori di documenti pesati, operatori di query, ranking e accelerazione GIN. È adatta alla ricerca interna di un'applicazione quando corpus e regole di pertinenza restano gestibili. Gli indici trigram possono supportare somiglianza e corrispondenze di sottostringhe per nomi o identificatori.

Gli indici testuali MongoDB gestiscono la ricerca di parole di base. La piattaforma gestita MongoDB offre anche funzioni separate di ricerca e ricerca vettoriale per carichi di recupero e pertinenza più ricchi. Considerale servizi specifici della distribuzione quando confronti portabilità, prezzi, backup e sviluppo locale.

La ricerca vettoriale cambia il tipo di query, non elimina la necessità di una fonte transazionale di verità. PostgreSQL può aggiungere l'indicizzazione vettoriale tramite estensioni, mentre le distribuzioni MongoDB possono associare documenti operativi a servizi di ricerca vettoriale supportati. Valuta recall, filtri, tempi di creazione dell'indice, visibilità degli aggiornamenti e costo sugli embedding dell'applicazione.

Per il geospaziale, PostgreSQL usa spesso l'estensione PostGIS per geometrie avanzate, sistemi di coordinate e analisi spaziale. MongoDB offre indici e operatori geospaziali adatti a query di applicazioni basate sulla posizione. Scegli l'opzione più semplice solo dopo aver elencato le operazioni reali: trovare punti vicini richiede molto meno di riparare poligoni o eseguire join spaziali complessi.

Le raccolte di serie temporali MongoDB organizzano le misurazioni in bucket interni e supportano la scadenza basata sul tempo. PostgreSQL gestisce dati temporali con partizionamento, indici BRIN ed estensioni opzionali. Telemetria a volumi molto alti può appartenere a un archivio analitico dedicato dopo l'ingestione, soprattutto quando conservazione lunga e scansioni ampie contano più degli aggiornamenti transazionali.

Prestazioni e benchmark rappresentativi

La disposizione dei dati, la copertura degli indici, la dimensione del working set e le impostazioni di durabilità contano di solito più dei benchmark generici MongoDB contro PostgreSQL. Un test credibile riproduce distribuzione dei dati e concorrenza dell'applicazione.

MongoDB può offrire letture a bassa latenza quando una richiesta corrisponde a un documento indicizzato. Il vantaggio si riduce se i documenti sono grandi, le risposte richiedono pochi campi sparsi o le relazioni richiedono ricerche ripetute. Gli array incorporati aumentano le voci di indice e possono rendere gli aggiornamenti sempre più costosi.

PostgreSQL può eseguire join complessi in modo efficiente quando le statistiche sono corrette e le colonne di join sono indicizzate. Le prestazioni peggiorano quando una query crea risultati intermedi enormi, sposta ordinamenti o hash su disco oppure recupera ripetutamente molte pagine non correlate. Selezionare solo le colonne necessarie e correggere errori di modello spesso conta più che riscrivere la sintassi SQL.

Ogni indice secondario aumenta il lavoro di scrittura in entrambi i sistemi. Valori JSONB grandi, righe ampie, documenti sovradimensionati e dati denormalizzati duplicati aumentano l'I/O. Tempeste di connessioni possono esaurire risorse anche con query veloci, quindi usa pool limitati e prova il comportamento di riconnessione durante il failover.

Un benchmark utile dovrebbe conservare queste condizioni:

• Carica abbastanza dati da rappresentare il rapporto previsto tra working set e memoria disponibile.
• Replica impostazioni di coerenza, journaling, replica e conferma della produzione.
• Riproduci le principali operazioni applicative con proporzioni realistiche di letture e scritture.
• Includi distribuzioni sbilanciate, clienti molto attivi, account grandi, record mancanti e filtri peggiori.
• Registra throughput e latenza p50, p95 e p99 durante carico stabile ed eventi di ripristino.

Esegui una modifica controllata alla volta. Confronta tabelle normalizzate con JSONB, documenti incorporati con riferimenti o indici alternativi mantenendo costanti hardware e semantica delle richieste. I microbenchmark con cache calda non prevedono pressione dei backup, ritardo di replica, checkpoint o prestazioni dopo la perdita del primario.

La pianificazione della capacità deve includere la crescita di dati e indici. Un indice che entra in memoria al lancio può dominare la latenza dopo un anno. Ripeti il test con il volume di dati previsto invece di estrapolare da un database vuoto.

Scalabilità orizzontale e distribuzione dei dati

MongoDB offre sharding integrato per distribuire le scritture. PostgreSQL combina più spesso scalabilità verticale, partizionamento e repliche prima di adottare un'architettura distribuita separata. La scala orizzontale introduce decisioni di routing e proprietà che influenzano ogni query.

Un cluster MongoDB sharded distribuisce documenti secondo una shard key. Una buona chiave ha cardinalità sufficiente, evita di concentrare scritture monotone, supporta predicati di routing comuni e distribuisce uniformemente lo storage. Una query che omette la shard key può contattare ogni shard, aumentando latenza e uso di risorse.

Lo sharding hashed può distribuire in modo più uniforme identificatori sequenziali, ma riduce la località degli intervalli. Lo sharding basato su intervalli supporta intervalli mirati, ma può creare un'estremità calda. Le zone possono collocare intervalli selezionati su shard designati per regole di clientela o geografiche. Il resharding può correggere una scelta sbagliata, ma spostare un grande dataset attivo richiede pianificazione e capacità libera.

Le transazioni MongoDB possono attraversare gli shard, ma il coordinamento tra shard costa più delle operazioni instradate a uno solo. Le applicazioni che includono l'identificatore del cliente sia nella shard key sia nelle query comuni possono spesso mantenere il lavoro correlato locale.

Il partizionamento nativo PostgreSQL divide una tabella logica in tabelle figlie, di solito per tempo, cliente o altro valore di routing. Il pruning delle partizioni riduce le scansioni e le partizioni semplificano le operazioni di conservazione. Il solo partizionamento nativo non distribuisce le scritture tra macchine e non va descritto come sharding.

Le repliche di lettura PostgreSQL possono spostare traffico di lettura idoneo dal primario. Non aumentano la capacità di scrittura del primario e le repliche asincrone possono restituire dati meno recenti. L'applicazione deve decidere quali letture tollerano questo ritardo.

Quando un singolo writer PostgreSQL non basta più, il team può fare sharding nel codice applicativo, adottare un'estensione o servizio PostgreSQL distribuito oppure separare i domini in database indipendenti. Ogni opzione cambia il comportamento di join tra shard, univocità, sequenze e transazioni. Prova questi limiti prima che l'applicazione dipenda da operazioni globali.

I requisiti di scala vanno espressi con numeri: operazioni di scrittura attese al secondo, dimensione del dataset, concentrazione dei clienti più attivi, collocazione regionale e obiettivi di ripristino sono più utili di una generica richiesta di scalabilità orizzontale.

Replica, failover e ripristino

Entrambi i database possono offrire alta disponibilità, ma il comportamento di ripristino dipende da topologia, politica di conferma, automazione e test ripetuti. La sola replica non garantisce un'interruzione breve o perdita di dati zero.

MongoDB opera comunemente come replica set con un primario e più secondari. I membri eleggono un nuovo primario quando quello corrente non è disponibile. Le applicazioni dovrebbero usare driver supportati, configurare timeout di selezione server e operazione e gestire gli errori transitori. Le retryable writes aiutano alcune operazioni, ma i tentativi devono comunque rispettare l'idempotenza dell'applicazione.

La write concern controlla quanti membri confermano una scrittura. La read preference decide se le letture idonee usano primario o secondari e la read concern controlla le garanzie di visibilità. Una configurazione a bassa latenza può esporre più rischio di errori o dati non aggiornati, quindi documenta la combinazione scelta per ciascun carico.

La replica fisica streaming PostgreSQL invia record di write-ahead log da un primario agli standby. La replica asincrona protegge disponibilità e latenza, ma può perdere transazioni confermate di recente se il primario viene distrutto prima che uno standby le riceva. La replica sincrona riduce questa esposizione aumentando però latenza di commit e sensibilità alla salute degli standby.

Il failover PostgreSQL viene normalmente coordinato da un servizio gestito o automazione esterna. La procedura deve promuovere uno standby adatto, reindirizzare i client e impedire al vecchio primario di accettare scritture in conflitto. Pool di connessioni e cache DNS possono prolungare l'interruzione percepita dopo la promozione.

I backup proteggono da guasti che la replica copia fedelmente, incluse cancellazioni accidentali e corruzione logica. Backup di base PostgreSQL più write-ahead log archiviati consentono il ripristino point-in-time. Le distribuzioni MongoDB possono usare snapshot coordinati e ripristino basato su oplog tramite strumenti appropriati o servizi gestiti.

Definisci separatamente recovery point objective e recovery time objective. Poi prova un ripristino completo in un ambiente isolato, verifica i dati dell'applicazione, ruota le credenziali ripristinate e registra il tempo trascorso. Uno snapshot riuscito non dimostra che un servizio completo possa essere ripristinato entro l'obiettivo.

Manutenzione operativa

PostgreSQL e MongoDB richiedono manutenzione ordinaria diversa, quindi l'esperienza del team può superare piccoli vantaggi di funzionalità. I servizi gestiti riducono parte del lavoro, ma non si occupano della progettazione delle query, delle decisioni di capacità o della verifica dei ripristini.

PostgreSQL crea versioni obsolete delle righe quando le transazioni aggiornano o eliminano dati. Autovacuum recupera spazio riutilizzabile, aggiorna le informazioni di visibilità e impedisce l'esaurimento degli ID di transazione. Transazioni di lunga durata possono ritardare la pulizia. Monitora tuple morte, crescita di tabelle e indici, avanzamento del vacuum, età delle transazioni e query che mantengono vive vecchie istantanee.

Anche le statistiche del planner richiedono attenzione. Valori sbilanciati o colonne correlate possono produrre stime errate e piani scadenti. Aumentare i target delle statistiche o creare statistiche estese può aiutare query selezionate. Rivedi le prestazioni dopo una forte crescita dei dati, non solo dopo modifiche al codice.

Il motore WiredTiger di MongoDB dipende molto da cache e compressione. Monitora pressione della cache, latenza del disco, crescita dei documenti, checkpoint, ritardo di replica e rapporto tra documenti esaminati e restituiti. Nelle distribuzioni sharded controlla bilanciamento, distribuzione diseguale dei chunk e operazioni che si disperdono tra gli shard.

I runbook ordinari dovrebbero coprire cinque aree:

• Raccolta delle query lente, responsabilità e soglie di correzione.
• Avvisi di capacità basati sul tasso di crescita, non solo sul riempimento attuale.
• Esercitazioni di ripristino con tempi registrati e passaggi di validazione.
• Rotazione delle credenziali e procedure di accesso d'emergenza.
• Aggiornamenti di versione provati con driver, estensioni, indici e piani di rollback.

Gli aggiornamenti maggiori PostgreSQL usano spesso pg_upgrade, replica logica o un processo di migrazione gestito. La compatibilità delle estensioni può determinare il percorso praticabile. Gli aggiornamenti MongoDB seguono sequenze di versione supportate e controlli Feature Compatibility Version; i cluster sharded richiedono un ordine accurato dei componenti.

Strumenti di esportazione logica come pg_dump e mongodump sono pratici per dataset più piccoli e ripristini selettivi. Su larga scala possono essere troppo lenti per obiettivi di ripristino rigorosi. Misura durata di esportazione e importazione con dati di dimensioni produttive prima di adottarli come metodo primario di disaster recovery.

Sicurezza e governance

Entrambi i database possono soddisfare requisiti di sicurezza impegnativi quando accesso, crittografia, audit e controlli di rete vengono progettati esplicitamente. Credenziali predefinite o rete privata da sole non creano un sistema verificabile.

I ruoli PostgreSQL possono ricevere privilegi a livello di database, schema, tabella, sequenza, funzione e colonna. Le viste possono esporre campi selezionati e la row-level security può limitare le righe in base al contesto utente o cliente. Mantieni la proprietà degli oggetti separata dai normali ruoli dell'applicazione, così un servizio compromesso non potrà modificare le proprie restrizioni.

I ruoli MongoDB concedono azioni su database, raccolte e risorse del cluster. Usa identità separate per letture dell'applicazione, scritture dell'applicazione, migrazioni, monitoraggio, backup e amministrazione. Evita di condividere tra servizi un'unica credenziale con privilegi estesi.

Un insieme pratico di controlli comprende:

• Richiedere TLS per il traffico client e di replica, verificando la gestione dei certificati in ogni driver.
• Conservare i segreti in un sistema gestito e ruotarli senza una pubblicazione completa dell'applicazione.
• Limitare i percorsi di rete ed evitare di esporre direttamente i listener del database a Internet.
• Registrare gli eventi di autenticazione, privilegi, schema e accesso a dati sensibili richiesti dalle policy.
• Verificare che analisti, supporto e account di automazione non superino i compiti assegnati.

La crittografia a riposo può combinare funzionalità del database, storage crittografato e chiavi gestite dal cloud. MongoDB supporta anche la crittografia lato client a livello di campo nelle distribuzioni supportate. Le applicazioni PostgreSQL spesso cifrano valori selezionati prima della memorizzazione quando gli amministratori del database non devono vedere il testo in chiaro. La crittografia modifica le possibilità di indicizzazione e query, quindi prima realizza un prototipo delle operazioni protette.

La governance richiede anche classificazione dei dati, conservazione, cancellazione, residenza e procedure di risposta agli incidenti. La collocazione regionale può sostenere obiettivi di residenza, ma la conformità dipende da backup, log, accesso del supporto, subfornitori e ogni sistema che riceve i dati.

Costi, licenze e costo totale di gestione

Il database meno costoso è quello che soddisfa il carico con infrastruttura, commissioni di servizio e impegno tecnico accettabili. Il prezzo della licenza da solo determina raramente il costo totale.

Il costo di calcolo cresce con query complesse, compressione, manutenzione degli indici, attività in background e replica. Lo storage include indici, log conservati, backup, spazio temporaneo e dati duplicati dalla denormalizzazione. Tre repliche contenenti dati memorizzano più copie ancora prima di considerare snapshot e trasferimenti tra regioni.

PostgreSQL usa la permissiva PostgreSQL License ed è disponibile in molte distribuzioni autogestite e gestite. Supporto commerciale e servizi cloud sono acquisti facoltativi. Le estensioni possono avere licenze proprie e vanno valutate separatamente.

MongoDB Community Server usa la Server Side Public License, disponibile come sorgente ma non approvata dalla Open Source Initiative. MongoDB Atlas e il supporto commerciale seguono prezzi e termini del fornitore. Le organizzazioni che integrano o offrono funzionalità di database come servizio dovrebbero far esaminare i termini applicabili a un consulente legale invece di presumere che coincidano con una licenza open source permissiva.

I database gestiti scambiano prezzi unitari più alti con provisioning, patch, backup, integrazioni di monitoraggio e parte del processo di failover automatizzati. Restano comunque al cliente qualità dello schema, query lente, gestione delle connessioni, classificazione dei dati e ripristino dell'applicazione.

Stima il costo totale con questi elementi:

• Numero di ambienti di produzione, staging, sviluppo, disaster recovery e temporanei.
• Crescita di dati e indici nei prossimi 12-24 mesi.
• Repliche, regioni, conservazione dei backup e trasferimento di rete richiesti.
• Throughput di picco, memoria del working set e prestazioni dello storage previste.
• Tempo del personale per migrazioni, ottimizzazione, incidenti, audit ed esercitazioni di ripristino.

Un database già ben supportato dal team può costare meno di un'alternativa tecnicamente interessante. Formazione, nuova automazione, procedure di reperibilità riviste e rischio di migrazione sono costi reali.

Adattamento all'applicazione per carico di lavoro

PostgreSQL è la scelta predefinita più solida per sistemi di registrazione ricchi di relazioni, mentre MongoDB trova spazio in domini con documenti variabili e di proprietà indipendente. I flussi specifici mostrano l'adattamento meglio di etichette generiche come applicazione web o sistema aziendale.

Un modello di account SaaS include spesso organizzazioni, iscrizioni, inviti, ruoli, abbonamenti, fatture, diritti e record di audit. Unicità e regole tra entità sono centrali e gli amministratori finiranno per chiedere report non previsti al lancio. PostgreSQL si adatta bene a questo schema.

Un catalogo prodotti può contenere insiemi di attributi diversi per abbigliamento, elettronica, componenti industriali e categorie personalizzate del cliente. MongoDB può memorizzare ogni prodotto come documento coerente senza creare una tabella universale rada. PostgreSQL con JSONB resta competitivo quando i prodotti partecipano molto a tabelle prezzi, movimenti di inventario, accordi con fornitori e report relazionali.

Un dominio di gestione dei contenuti spesso si adatta a documenti con blocchi, localizzazione, metadati e stato di pubblicazione. MongoDB funziona bene quando ogni contenuto viene letto e revisionato come un'unità. PostgreSQL può essere preferibile quando autorizzazioni editoriali, pianificazione, riferimenti tra contenuti e report sono più impegnativi della variazione dei documenti.

Libri mastri finanziari, prenotazioni di inventario e record di fatturazione favoriscono PostgreSQL. Un progetto append-only non elimina il bisogno di unicità, scritture bilanciate, query di riconciliazione e invarianti su più record.

I sistemi di eventi e telemetria richiedono un test più dettagliato. MongoDB può acquisire eventi in forma di documento e PostgreSQL può partizionare tabelle con molte aggiunte. A scala analitica sostenuta, il database operativo può alimentare un warehouse colonnare o un sistema per serie temporali dedicato. Conservazione, finestre di aggregazione, arrivi tardivi e dimensione delle scansioni devono decidere il percorso di archiviazione.

Un'architettura ibrida è giustificata quando le entità autorevoli restano in PostgreSQL e un dominio a documenti ha proprietà e modelli di accesso separati. Assegna una fonte di verità a ogni entità. Pubblica i cambiamenti con un processo outbox o change data capture, usa consumer idempotenti e pianifica consegne ritardate o ripetute. Evita doppie scritture sincrone che possono lasciare gli archivi incoerenti dopo un errore parziale.

Un metodo pratico per decidere

Un breve proof of concept con dati simili alla produzione è il modo più affidabile per risolvere una scelta ravvicinata tra MongoDB e PostgreSQL. Il test dovrebbe concentrarsi sulle parti difficili, non su una dimostrazione generica di creazione, lettura, aggiornamento e cancellazione.

Scegli tre flussi rappresentativi: la richiesta più comune, la query più complessa e l'operazione con il requisito di correttezza più rigoroso. Modella ogni flusso onestamente in entrambi i database. Non costringere PostgreSQL a imitare un document store con un'unica colonna JSON senza limiti e non costringere MongoDB a riprodurre uno schema molto normalizzato in molte raccolte.

Valuta ogni candidato per chiarezza del modello, correttezza, sforzo delle query, latenza misurata, familiarità operativa, ripristino, controlli di sicurezza e costo previsto. Pesa le categorie prima di vedere i benchmark. Un'applicazione finanziaria dovrebbe dare più peso a integrità e verificabilità che all'evitare migrazioni, mentre un prototipo di contenuti usa e getta può fare il contrario.

Rifiuta un progetto se dipende da una di queste ipotesi:

• Ogni query futura seguirà il modello di accesso della prima API.
• La validazione applicativa verrà eseguita correttamente per sempre su ogni percorso di scrittura.
• Un unico grande cliente si comporterà come il cliente mediano.
• La replica elimina il bisogno di backup ed esercitazioni di ripristino.
• Un secondo database ha poco costo operativo perché la prima distribuzione è gestita.

Per un'applicazione transazionale generica, PostgreSQL resta il punto di partenza più sicuro. Tabelle, SQL, vincoli, modello di transazione maturo e supporto JSONB lasciano spazio a dati strutturati e a dati semistrutturati selezionati. MongoDB dovrebbe prevalere perché il modello a documenti produce un progetto sensibilmente più semplice oppure perché il suo modello di distribuzione integrato risponde a requisiti misurati, non perché le migrazioni sembrano scomode.

Applicare la scelta ai progetti Koder.ai

PostgreSQL è il punto di partenza naturale per la maggior parte dei progetti Koder.ai perché lo stack principale della piattaforma usa React, Go, PostgreSQL e Flutter per le applicazioni mobili. Questa scelta si adatta a siti web, CRM, ERP, app mobili e altri sistemi transazionali creati comunemente tramite la sua interfaccia chat.

La modalità Planning dovrebbe individuare entità, relazioni, regole di unicità, conservazione dei dati e operazioni ad alto volume prima di iniziare la generazione. Le proprietà stabili appartengono a colonne tipizzate. Gli attributi facoltativi e specifici dell'attività possono usare JSONB quando la loro struttura varia davvero.

Koder.ai supporta esportazione del codice sorgente, distribuzione e hosting, domini personalizzati, snapshot e rollback. Snapshot e rollback dell'applicazione devono integrare la pianificazione delle migrazioni del database, non sostituirla. Tornare indietro con il codice dopo una modifica incompatibile dello schema può lasciare il codice precedente incapace di leggere dati nuovi.

Per i servizi Go generati, conserva le modifiche del database in migrazioni revisionate e rendi sicure le distribuzioni durante il periodo di transizione. Una sequenza comune consiste nell'aggiungere uno schema compatibile, pubblicare codice che comprende entrambi gli stati, aggiornare i dati, cambiare le letture e rimuovere la forma obsoleta in una versione successiva.

Koder.ai può eseguire applicazioni su infrastruttura AWS in diversi paesi per soddisfare requisiti di collocazione dei dati. Il progetto del database deve estendere questa scelta a repliche, backup, log, esportazioni analitiche e accesso amministrativo. La collocazione geografica è un controllo all'interno di un piano più ampio di privacy e governance.

L'aggiunta di MongoDB a un progetto basato su PostgreSQL dovrebbe seguire lo stesso standard di ogni altra dipendenza architetturale: definisci prima dell'implementazione dominio posseduto dai documenti, gestione degli errori, percorso di sincronizzazione, politica di backup e responsabilità operativa.

Checklist di migrazione e adozione

Una migrazione di database riesce quando il team può dimostrare completezza dei dati, compatibilità dell'applicazione e un passaggio recuperabile. Convertire la sintassi è soltanto una parte del lavoro.

Inizia inventariando tabelle o raccolte, volume dei dati, indici, vincoli, modelli di query, regole di conservazione e ogni writer. Individua semantiche che non si traducono direttamente, come chiavi esterne relazionali che diventano riferimenti, array incorporati che diventano tabelle figlie, differenze di precisione numerica, confronti sensibili alle maiuscole o gestione dei timestamp.

Crea query di riconciliazione prima di spostare i dati di produzione. I soli conteggi non bastano. Confronta totali per cliente e data, verifica l'univocità, campiona record grandi, controlla relazioni orfane e calcola saldi aziendali quando necessario.

Una migrazione controllata include di norma queste fasi:

• Esegui una copia iniziale in blocco e registra i record rifiutati o trasformati.
• Cattura i cambiamenti successivi con log, outbox o un meccanismo di change data capture.
• Esegui letture shadow o confronta risposte campionate senza modificare il comportamento visibile agli utenti.
• Effettua il passaggio con una modifica di routing reversibile monitorando errori e ritardo.
• Mantieni il vecchio archivio in sola lettura fino al completamento della riconciliazione e della finestra di rollback.

La doppia scrittura dal codice applicativo è rischiosa a meno che entrambe le scritture siano idempotenti e l'errore parziale venga riconciliato esplicitamente. Preferisci una fonte impegnata più un record di consegna asincrona che possa essere ritentato.

Dopo il passaggio, ricostruisci le basi operative. Piani di query, dimensioni dei pool di connessione, soglie di avviso, durata dei backup e previsioni di capacità del vecchio motore non si trasferiscono automaticamente. La migrazione è completa solo dopo che il nuovo database ha superato un'esercitazione di ripristino e il team sa gestirlo durante un guasto.