Perché scegliere un database gestito

Con un managed database Google Cloud si occupa delle attività operative ripetitive — patching, backup, replica, high availability e scaling — mentre il team resta concentrato sull’applicazione e sul valore di business. La domanda d’esame non è mai “come si configura”, ma “quale prodotto risolve questa esigenza”. Per rispondere servono due assi di ragionamento: il modello dati (relazionale con schema rigido e SQL, oppure NoSQL flessibile) e la scala richiesta (transazionale regionale oppure distribuita a livello globale con consistenza forte). Tenere a mente questi due assi permette di eliminare rapidamente le opzioni sbagliate.

I database relazionali gestiti

Cloud SQL è il database relazionale gestito per eccellenza: offre MySQL, PostgreSQL e SQL Server. È la scelta naturale per migrare un’applicazione esistente (lift-and-shift) o per un nuovo carico transazionale tradizionale — gestionali, e-commerce, siti web, back-office. Copre esigenze regionali con dati strutturati e transazioni classiche, ma non scala orizzontalmente a livello planetario: quando serve una portata globale, Cloud SQL non è la risposta.

AlloyDB è compatibile con PostgreSQL ma pensato per prestazioni molto più elevate. È la scelta quando un carico PostgreSQL diventa troppo impegnativo per Cloud SQL: alto throughput transazionale unito a query analitiche veloci sugli stessi dati, mantenendo però la compatibilità con l’ecosistema PostgreSQL. Resta un database regionale ad alte prestazioni, non una soluzione a scala globale.

Cloud Spanner è il database relazionale che unisce SQL e transazioni con scala orizzontale globale e strong consistency. È la risposta agli scenari di scala planetaria dove servono contemporaneamente coerenza forte, disponibilità elevatissima e distribuzione su più regioni: sistemi finanziari, inventari globali, piattaforme che devono crescere senza limiti pratici mantenendo dati sempre coerenti. Ha un costo superiore, quindi si sceglie quando la combinazione “relazionale + globale + consistente” è davvero un requisito, non per un’app regionale.

I database NoSQL gestiti

Cloud Bigtable è un database NoSQL wide-column progettato per throughput altissimo e bassa latenza su volumi enormi di dati. È l’opzione tipica per time-series, dati IoT e sensori, monitoraggio, personalizzazione e workload analitici su miliardi di righe. Attenzione: non è relazionale, non gestisce join complessi né transazioni multi-riga sofisticate. Se la domanda parla di flussi continui di misurazioni ad alta velocità, l’indizio punta a Bigtable.

Firestore è un database documentale (document store) pensato per lo sviluppo di applicazioni web e mobile. Offre schema flessibile, sincronizzazione in tempo reale e supporto offline, il che lo rende ideale per app che gestiscono profili utente, cataloghi, chat e stati applicativi. È la scelta quando il focus è la rapidità di sviluppo di un’app, non l’analisi massiva o la coerenza relazionale rigida.

Come orientare la scelta

Parti dal modello dati: se servono schema rigido, SQL e transazioni classiche, resta nella famiglia relazionale (Cloud SQL, AlloyDB, Cloud Spanner); se i dati sono flessibili o enormi in scrittura, guarda al NoSQL (Firestore per le app, Bigtable per il throughput). Poi valuta la scala: regionale porta a Cloud SQL o AlloyDB, globale con consistenza forte porta a Cloud Spanner. Ricorda infine che BigQuery non è un database transazionale (OLTP): è un data warehouse analitico, quindi non va scelto per gestire le operazioni di un’applicazione in tempo reale.

Trappole tipiche d’esame

  • Scala globale + consistenza forte per dati relazionali → Cloud Spanner: Cloud SQL è distrattore frequente, ma è regionale e non scala orizzontalmente a livello planetario.
  • Time-series o dati IoT ad altissimo volume → Cloud Bigtable: è NoSQL wide-column; scartare Cloud SQL e Spanner, pensati per dati relazionali, non per flussi massivi a bassa latenza.
  • App mobile/web con schema flessibile e sync real-time → Firestore: il database documentale, non Bigtable (che serve throughput analitico, non lo sviluppo di app).
  • Analisi su grandi volumi storici → BigQuery, non un database OLTP: attenzione a chi propone Bigtable o Cloud SQL per reportistica analitica su data warehouse.
  • Carico PostgreSQL esigente oltre Cloud SQL → AlloyDB: mantiene la compatibilità PostgreSQL con prestazioni superiori, senza passare a Spanner se la scala resta regionale.
  • Migrazione lift-and-shift di un DB relazionale esistente → Cloud SQL: MySQL, PostgreSQL o SQL Server gestiti; non serve riscrivere l’app per Spanner.