Il tuo database locale va in crash proprio quando il cliente ha bisogno dei dati. Oppure il server fisico è saturo e migrare significa notti insonni. Il problema è sempre lo stesso: gestire MongoDB on-premise richiede tempo, competenze e budget che una PMI non ha. MongoDB Atlas risolve questo, ma solo se lo configuri bene. Un cluster mal impostato costa più di un server dedicato. Vediamo come si fa, partendo dai numeri.
Perché MongoDB Atlas conviene rispetto a un server dedicato?
Noi, di Meteora Web, ragioniamo da ex contabili. Un server dedicato significa: costo hardware, elettricità, qualcuno che fa backup, qualcuno che applica le patch di sicurezza. Moltiplicato per 12 mesi. MongoDB Atlas toglie tutto questo, ma attenzione: il prezzo orario sembra basso, poi arriva la sorpresa in fattura se non scegli la tier giusta.
La convenienza non è solo economica. È anche operativa. Con Atlas hai alta disponibilità di serie, backup automatici e un pannello che ti mostra la salute del cluster. Per una PMI che non ha un DBA in organico, questo vale oro. Il nostro consiglio: parti dalla tier M10 (circa 57 dollari al mese) per la produzione. La M0 gratuita va bene solo per sviluppo, non per un cliente che paga.
Come stimare i costi prima di creare il cluster?
Atlas ha un calcolatore, ma noi usiamo una regola pratica. Per un'applicazione con 10.000 utenti attivi al mese, con letture e scritture moderate, una M10 basta. Se hai picchi, attiva l'autoscaling. Se devi risparmiare, scegli regioni come eu-central-1 (Francoforte) che hanno prezzi competitivi. E ricorda: i costi di trasferimento dati tra regioni si pagano. Tieni tutto nella stessa area geografica.
Sponsored Protocol
Checklist operativa:
- Calcola il numero di operazioni al secondo (letture + scritture)
- Stima lo storage: 1 GB per 100.000 documenti semplici è una buona base
- Scegli la tier: M0 (dev), M10 (produzione leggera), M20+ (produzione intensa)
- Attiva l'autoscaling solo se i picchi sono prevedibili
Come si crea un cluster MongoDB Atlas nel 2026?
La procedura è cambiata poco, ma i dettagli fanno la differenza. Non cliccare "Create" al primo tentativo. Prima pensa a chi userà il database e da dove. Se la tua app è in Europa, il cluster deve stare in Europa. La latenza non è un dettaglio: 100 millisecondi in più per ogni query si sentono tutti.
Passaggi pratici per il setup iniziale
Prima cosa: crea l'account con un'email dedicata, non quella personale. Poi scegli il provider (AWS, Azure o GCP) e la region. Noi usiamo AWS con eu-central-1 per i clienti italiani. La latenza è bassa e i prezzi sono stabili.
Poi arriva il momento critico: la sicurezza. Atlas ti chiede di creare un utente database. Non usare mai la password di default. Genera una password complessa e salvala in un password manager. Per l'IP, non mettere 0.0.0.0/0 che apre a tutto il mondo. Inserisci solo l'IP del tuo server applicativo. Se l'IP cambia, lo aggiorni dal pannello.
Sponsored Protocol
# Connessione da terminale con la connection string di Atlas
docker run -it --rm mongo:7 mongosh "mongodb+srv://admin:LA_TUA_PASSWORD@cluster0.abcde.mongodb.net/?retryWrites=true&w=majority" --ping
Se il ping risponde, sei connesso. Se no, controlla l'IP nella whitelist. L'errore più comune è proprio quello: IP non autorizzato.
Quale configurazione di rete scegliere per MongoDB Atlas?
Atlas offre due opzioni: Private Endpoint e IP Access List. Per una PMI, la IP Access List è sufficiente. Costa meno e si configura in due minuti. Il Private Endpoint è per chi ha requisiti di compliance stringenti o traffico enorme. Noi lo consigliamo solo se il cliente lavora con dati sanitari o finanziari.
La regola è semplice: mai esporre MongoDB direttamente su internet. Anche con la whitelist, il traffico viaggia cifrato (TLS). Ma se puoi, usa un VPC peering. Così il traffico tra la tua app e il database non passa mai dalla rete pubblica. La latenza scende e la sicurezza sale.
Come configurare la rete in modo sicuro?
Accedi al pannello Atlas, vai su Network Access e aggiungi l'IP del tuo server. Se usi un servizio serverless come Vercel o Netlify, gli IP sono dinamici. In quel caso, usa un proxy o un server intermedio. Non è elegante, ma funziona. In alternativa, valuta l'API di Atlas che permette di aggiornare la whitelist via script.
Sponsored Protocol
Come si proteggono i dati con backup e autenticazione?
La sicurezza non è solo la whitelist. È anche backup automatici e autenticazione forte. Atlas include backup continui nelle tier a pagamento. Attivali subito, non dopo il primo disastro. Il restore è semplice: selezioni il timestamp e Atlas ripristina il cluster.
Per l'autenticazione, usa sempre SCRAM-SHA-256 (il default) e mai credenziali condivise tra sviluppatori. Crea un utente per ogni servizio. Se un'app viene compromessa, revochi solo quell'utente, non tutto.
// Connessione con Node.js e variabile d'ambiente per la password
const { MongoClient } = require('mongodb');
const uri = process.env.MONGODB_URI;
const client = new MongoClient(uri, { useNewUrlParser: true, useUnifiedTopology: true });
async function run() {
try {
await client.connect();
const db = client.db('nome_database');
console.log('Connesso a MongoDB Atlas');
} finally {
await client.close();
}
}
run().catch(console.dir);
Come monitorare le performance del cluster Atlas?
Un cluster non si configura e si dimentica. Va monitorato. Atlas ha un pannello Metrics che mostra CPU, memoria, operazioni al secondo e latenza. Noi controlliamo questi numeri ogni settimana per i clienti. Se la CPU è sopra l'80% per più di 10 minuti, è il momento di fare qualcosa.
Sponsored Protocol
Le metriche da tenere d'occhio sono tre: query latency, scanned objects e connections. Se la latenza sale, probabilmente manca un indice. Se gli scanned objects sono alti, le query non usano gli indici esistenti. Se le connessioni sono troppe, il connection pooling non è configurato bene.
Come si leggono le metriche senza essere un DBA?
Vai su Monitoring nel pannello Atlas. Guarda il grafico "Query Targeting". Se vedi picchi di "Scanned Objects / Returned", hai un problema di indici. Crea un indice composto sulle query più frequenti. Con una sola riga di codice risolvi il 90% dei problemi di performance.
// Creare un indice composto per una query frequente
db.collection('ordini').createIndex({ cliente_id: 1, data_ordine: -1 });
Come migrare un database esistente su MongoDB Atlas?
La migrazione è il momento in cui si rompono le cose. Non farla di fretta. Il metodo più sicuro è mongodump e mongorestore. Funziona anche con database grandi, ma richiede tempo. Per un database da 10 GB, ci vogliono circa 20 minuti con una buona connessione.
In alternativa, Atlas ha Live Migration che sincronizza i dati senza downtime. La usiamo per i clienti che non possono permettersi nemmeno un minuto di fermo. Il processo è: colleghi Atlas al tuo MongoDB locale, lui copia i dati e poi fai lo switch. Semplice, ma va testato prima.
Sponsored Protocol
Passaggi per una migrazione senza dolore
- Esporta i dati con
mongodump --uri="mongodb://localhost:27017" - Importa con
mongorestore --uri="mongodb+srv://user:pass@cluster.mongodb.net" - Verifica il conteggio dei documenti:
db.collection.countDocuments() - Testa l'applicazione contro il nuovo cluster
- Aggiorna la connection string nell'applicazione
Un errore comune: dimenticare gli indici. mongorestore ripristina i dati, ma non sempre gli indici. Ricreali dopo la migrazione. Un database senza indici è come un archivio senza etichette: trovi tutto, ma ci metti ore.
Cosa fare adesso
Hai letto la teoria, ora agisci. La prossima ora la dedichi a queste tre cose:
- Crea un cluster M0 gratuito su Atlas e carica un dataset di prova. Non serve una carta di credito.
- Configura la whitelist con il tuo IP e collega il tuo computer con
mongosh. Se non hai MongoDB locale, usa il Docker container che ti abbiamo mostrato. - Scrivi un piccolo script Node.js che legge e scrive un documento. Se funziona, hai capito il 70% del lavoro.
Se ti serve una mano con la migrazione o con l'ottimizzazione delle query, siamo qui. Lavoriamo con MongoDB Atlas ogni giorno, e sappiamo dove si nascondono le trappole. Prima di lanciare in produzione, fai un test di carico. Costa poco e ti salva da brutte sorprese.
