MongoDB 9.0 introduce limiti alle risorse che possono far fallire le query esistenti
MongoDB 9.0 introduce protezioni contro le operazioni sul database che consumano molte risorse, ma queste stesse protezioni possono far fallire richieste che prima venivano completate correttamente. In un'analisi pubblicata da Percona il 9 ottobre 2026, Ivan Groenewold descrive una versione con utili miglioramenti delle prestazioni e della gestione operativa, anziché un cambiamento fondamentale nel modo in cui i team gestiscono il database. La sua raccomandazione principale è di testare e comprendere le modifiche prima di introdurle nei servizi in produzione.
La distinzione è importante anche al di là di MongoDB: un aggiornamento del database può migliorare l'affidabilità complessiva, modificando però ciò che le singole applicazioni possono fare. Nonostante la promozione incentrata sull'intelligenza artificiale (AI) e su Atlas, il servizio di database gestito di MongoDB, Groenewold sostiene che questa versione sembri più un aggiornamento incrementale alla 8.4 che un grande salto alla 9.0.
I limiti alle risorse cambiano il comportamento delle applicazioni
Un'aggiunta importante è il limite di memoria per operazione, ossia un tetto alla memoria che una singola attività del database può consumare. Il valore predefinito è pari a 1 GB o al 20% della memoria disponibile sul server, a seconda di quale sia il maggiore. Un'operazione che supera questa soglia può fallire. Ciò offre un ulteriore modo per contenere un'aggregazione, un'attività che combina o riepiloga i record memorizzati, prima che le sue esigenze di memoria sottraggano risorse agli altri carichi di lavoro. Significa anche che una richiesta completata su MongoDB 8.x potrebbe non essere completata sulla versione 9.0.
MongoDB 9.0 limita inoltre, per impostazione predefinita, a 10.000 le transazioni multidocumento aperte contemporaneamente. Queste transazioni raggruppano modifiche a più record in un'unica unità logica di lavoro. Il limite serve a impedire che un carico di lavoro consumi risorse senza alcun vincolo. Nessuna delle due protezioni elimina la necessità di testare il comportamento delle applicazioni: proteggere il server e completare correttamente tutte le richieste esistenti sono risultati diversi.
Le prestazioni dichiarate richiedono verifiche nel proprio ambiente
I benchmark di MongoDB, riportati da Groenewold, confrontano la versione 9.0 con la 8.0 e dichiarano operazioni findOne, che recuperano un record, fino al 35% più veloci; operazioni updateOne, che modificano un record, fino al 30% più veloci; una capacità di elaborazione delle transazioni superiore del 20%, ossia più lavoro transazionale completato in un dato intervallo di tempo; e una capacità di elaborazione doppia sulle istanze di grandi dimensioni. Groenewold osserva che il significato di «istanze di grandi dimensioni» non è chiaro nel materiale che ha esaminato.
Questi numeri sono misurazioni del fornitore, non test condotti da Percona o da questa testata. Al momento della stesura, Groenewold ha dichiarato di non essere riuscito a trovare la metodologia dei test o i risultati grezzi. I miglioramenti riportati non vanno quindi considerati una previsione per una specifica applicazione. Le prestazioni dipendono dagli indici, strutture di ricerca che aiutano a individuare i dati; dalle dimensioni dei documenti, ossia dei singoli record del database; dal working set, i dati utilizzati attivamente; dal sistema di archiviazione; e da altre caratteristiche del carico di lavoro. Restano necessari test rappresentativi prima di presumere che un servizio in produzione diventi più veloce del 35%.
Visibilità sulle scritture e ottimizzazione più mirata
La nuova versione estende $queryStats, lo strumento di MongoDB che fornisce statistiche sulle operazioni del database, oltre le letture, includendo inserimenti, aggiornamenti ed eliminazioni. Questo è importante quando si analizza un server molto impegnato che dedica gran parte del tempo a modificare i dati anziché a recuperarli. I team ottengono visibilità su letture e scritture in base alla forma della query, cioè lo schema strutturale di una richiesta al database, indipendentemente dai suoi valori specifici.
C'è un aspetto di compatibilità da considerare per il software di monitoraggio: nella versione 9.0 sono cambiate la struttura e la serializzazione dell'output di $queryStats. La serializzazione è il modo in cui le informazioni vengono rappresentate per il trasferimento o l'elaborazione. Qualsiasi strumento che utilizza queste statistiche deve essere verificato prima di un aggiornamento, senza dare per scontato che continui a interpretare correttamente l'output.
MongoDB 9.0 amplia inoltre querySettings, i controlli che definiscono come vengono gestiti determinati schemi di richiesta, e aggiunge opzioni per singola query. Un'ottimizzazione più mirata può evitare di modificare un'impostazione dell'intero server per soddisfare una sola richiesta problematica. Su infrastrutture condivise questa distinzione è utile, perché una modifica globale che favorisce un carico di lavoro può danneggiarne un altro.
La ricerca sui dati cifrati migliora, ma la migrazione richiede attenzione
Queryable Encryption, una funzionalità che consente di effettuare ricerche sui dati cifrati, introduce in disponibilità generale le query per prefisso, suffisso e sottostringa sulle stringhe cifrate. Le applicazioni possono cercare testo all'inizio, alla fine o all'interno di un valore testuale cifrato. Questo amplia l'utilità della funzionalità per le applicazioni che necessitano di dati protetti sui quali effettuare ricerche.
Tuttavia, l'implementazione della versione 9.0 è incompatibile con l'implementazione di Queryable Encryption Public Preview presente in MongoDB 8.2 e 8.3. Groenewold osserva inoltre che Automatic Encryption, che gestisce la cifratura senza che il codice applicativo debba eseguire manualmente ogni passaggio, resta esclusa dalla Community Edition. Individua in questa restrizione legata all'edizione un ostacolo all'adozione. I team dovrebbero esaminare sia la compatibilità sia la disponibilità nelle diverse edizioni, anziché considerare la ricerca sui dati cifrati una semplice sostituzione dell'implementazione esistente.
Le modifiche meno visibili meritano test specifici
Groenewold evidenzia cambiamenti di comportamento nei confronti con null tramite percorsi con notazione a punti, ossia verifiche di campi annidati rispetto a un valore null; nella gestione delle date in JavaScript lato server, cioè codice eseguito all'interno del database; e nei change stream durante le elezioni. I change stream notificano alle applicazioni le modifiche ai dati, mentre un'elezione seleziona quale membro del database assume il ruolo primario. Le applicazioni con componenti personalizzati che ricevono le notifiche dei change stream dovrebbero essere testate durante questa transizione.
Altre aree interessate includono renameCollection tra database, il comando utilizzato per spostare una raccolta di record da un database all'altro, e la validazione BSON, ossia i controlli sul formato dei documenti Binary JSON di MongoDB. Le applicazioni che utilizzano JavaScript lato database necessitano di verifiche sulla gestione delle date. Quelle che memorizzano documenti con strutture differenti dovrebbero testare i confronti con null su dati realistici. La fonte identifica queste aree come soggette a cambiamenti di comportamento senza descrivere nel dettaglio ogni nuova regola; il loro impatto preciso va quindi verificato sull'applicazione interessata.
Percona afferma che sono già iniziati i lavori su Percona Server for MongoDB 9.0, o PSMDB, e che ulteriori informazioni arriveranno in seguito. Groenewold sottolinea che PSMDB offre anche l'autenticazione LDAP, ossia verifiche dell'identità tramite una directory che utilizza il Lightweight Directory Access Protocol; la registrazione di audit, cioè registrazioni delle attività del database; il backup a caldo, ossia backup eseguiti mentre il database è in funzione; e la cifratura dei dati a riposo, che protegge i dati memorizzati. Secondo Percona, queste funzionalità sono disponibili senza una licenza Enterprise Edition né i costi di licenza aggiuntivi associati a MongoDB Enterprise.
Per le organizzazioni che cercano supporto operativo, i servizi di database gestiti, backup e monitoraggio di AEU Data contribuiscono a mantenere i servizi di database protetti e affidabili, ma non sostituiscono i test di aggiornamento specifici per ciascuna applicazione.