India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Google Cloud Databases: Cloud SQL, AlloyDB, Spanner & Firestore
Google Cloud's database portfolio covers managed relational engines (Cloud SQL and AlloyDB for PostgreSQL), globally consistent Spanner, document-oriented Firestore and in-memory Memorystore. NTSPL selects the engine per workload, migrates from on-premises MySQL, PostgreSQL, SQL Server or Oracle using Database Migration Service, and designs India-resident high availability across Mumbai and Delhi for regulated Indian businesses.
Google Cloud services in scope
The Problem Cloud SQL (MySQL, PostgreSQL, SQL Server) and AlloyDB for PostgreSQL Solve
Database decisions on Google Cloud are hard to reverse, which is why most of the trouble we see comes from choosing by habit. A team picks Cloud SQL for a ledger that will outgrow a single primary within 18 months, or picks Spanner for a 200 GB CMS that would run happily on Cloud SQL for a fraction of the cost. Others move a PostgreSQL reporting database to Cloud SQL and keep fighting slow analytical queries that AlloyDB's columnar engine would answer from memory. The engine, its edition and its replication topology set your availability ceiling and your bill.
NTSPL profiles each database before recommending anything: write rate, read-to-write ratio, largest table growth, transaction patterns, extensions in use and recovery objectives. We then map it to Cloud SQL Enterprise or Enterprise Plus, AlloyDB, Spanner or Firestore, design the HA and cross-region layout across asia-south1 and asia-south2, and run migrations through Database Migration Service with continuous replication so cutover windows are measured in minutes.
Choosing a Google Cloud Database Engine for Your Workload (and When Not To)
Signals that point to databases on Google Cloud
- A self-managed MySQL or PostgreSQL primary is above 70% CPU at peak and the only plan on the table is a bigger server.
- Recovery today relies on nightly dumps, so your real RPO is up to 24 hours despite a stated target of 15 minutes.
- Reporting queries against the OLTP database push transaction p95 latency above 500 ms during business hours.
- Oracle licence renewal is due and the application uses PL/SQL that could run on PostgreSQL with conversion.
- Expansion plans or regulator expectations require surviving a full regional outage while keeping data in India.
When a different approach is better
- Petabyte-scale analytics with ad hoc scans belong in BigQuery, not in AlloyDB's columnar engine or Spanner.
- Applications that depend on Oracle RAC-specific features with no near-term rewrite budget may need Oracle Database@Google Cloud or Bare Metal Solution rather than PostgreSQL.
- Small internal apps with a few hundred users and no HA requirement rarely justify Spanner or AlloyDB; a Cloud SQL Enterprise edition instance is enough.
Google Cloud Database Building Blocks: Cloud SQL, AlloyDB, Spanner, Firestore, Memorystore and DMS
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Cloud SQL (MySQL, PostgreSQL, SQL Server) | Fully managed relational database with automated backups, point-in-time recovery, regional HA and read replicas, offered in Enterprise and Enterprise Plus editions. | The workload fits on one primary, uses standard engine features, and you want the lowest-effort lift from self-managed MySQL, PostgreSQL or SQL Server. |
| AlloyDB for PostgreSQL | PostgreSQL-compatible database with disaggregated storage, read pool instances and a columnar engine that accelerates analytical queries on operational data. | A PostgreSQL workload needs higher transactional throughput than Cloud SQL or runs heavy reporting queries against live tables. |
| Spanner | Horizontally scalable relational database with external consistency, automatic sharding and regional, dual-region or multi-region configurations, including dual-region-india1 across Mumbai and Delhi. | Writes will exceed what a single primary can handle, or the business needs 99.999% availability with zero data loss across two Indian regions. |
| Firestore | Serverless document database with real-time listeners, offline mobile SDKs and automatic scaling. | Mobile or web clients need live-synchronised documents, and access patterns are key-based rather than relational joins. |
| Memorystore (Valkey, Redis Cluster, Redis, Memcached) | Managed in-memory data stores for caching, session state, rate limiting and leaderboards with sub-millisecond reads. | Database read load is dominated by repeated hot-key lookups that do not need transactional freshness. |
| Database Migration Service | Runs continuous, low-downtime migrations into Cloud SQL and AlloyDB, including heterogeneous Oracle and SQL Server to PostgreSQL migrations with conversion workspaces. | You need to move a live database with a cutover window of minutes rather than a weekend dump-and-restore. |
Regional HA primary with India cross-region recovery
Regional HA primary with India cross-region recovery
Application services on GKE or Cloud Run connect through the AlloyDB Auth Proxy or Cloud SQL Auth Proxy over Private Service Connect to a regional HA primary in asia-south1, with read pools serving reporting traffic and Memorystore absorbing hot-key reads. Changes replicate to a secondary cluster or cross-region replica in asia-south2, while Spanner workloads use dual-region-india1 for synchronous replication across both regions.
Select any component
Regional HA primary with India cross-region recovery: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Database Engineering Decisions: Engine Choice, Editions, Key Design and Replica Topology
Cloud SQL, AlloyDB or Spanner
We use three thresholds. If peak writes stay below roughly 5,000 transactions per second and the dataset is under a few terabytes with no analytical load, Cloud SQL is the cheapest safe choice. If it is PostgreSQL with mixed transactional and reporting load, or needs read scaling beyond a handful of replicas, AlloyDB fits. If writes must scale horizontally or the business requires 99.999% availability across Mumbai and Delhi, Spanner is the only managed option that does both.
Cloud SQL Enterprise versus Enterprise Plus edition
Enterprise Plus offers a 99.99% availability SLA inclusive of maintenance, larger machine configurations, a data cache on local SSD and faster planned maintenance with sub-second downtime. Enterprise edition carries a 99.95% SLA and suits internal tools and non-critical services. We move customer-facing payment, order or loyalty databases to Enterprise Plus, and keep reporting replicas and dev databases on Enterprise edition to control cost.
Spanner schema and key design
Spanner splits data by primary key ranges, so monotonically increasing keys such as timestamps or auto-increment IDs create write hotspots on one split. We use UUIDv4 or bit-reversed sequences for primary keys, interleave child tables like trip events under trips to keep related rows together, use commit timestamps for ordering, and keep secondary indexes only where Query Insights proves the read path needs them, since every index adds write cost.
Replica and recovery topology
Regional HA protects against zone failure only. For regional failure we add a Cloud SQL cross-region replica or AlloyDB secondary cluster in asia-south2, accepting an RPO of seconds and a manual or scripted promotion. Where the business needs RPO zero across regions, that is a Spanner dual-region decision, not a replication tuning exercise. Read replicas are never counted as backups; PITR and scheduled backups are tested by restoring into a scratch project each quarter.
Connection management and caching
Serverless and autoscaled clients can open thousands of connections and exhaust max_connections within seconds of a traffic spike. We size per-service pools, use Managed Connection Pooling on Cloud SQL Enterprise Plus or PgBouncer where needed, and put Memorystore for Valkey in front of read-mostly keys with TTLs of 30-300 seconds. Cache-aside is written so a cache outage degrades latency, never correctness, and we alert when cache hit rate drops below 80%.
How NTSPL Migrates a Production Database with Database Migration Service
Source profiling and compatibility scan
Capture two weeks of query statistics, extensions, stored procedures and collations, and run DMS conversion workspaces on heterogeneous sources to size code changes.
Target engine and edition build
Provision Cloud SQL, AlloyDB or Spanner with private connectivity, CMEK, HA and flags tuned from the source profile.
Continuous replication through DMS
Start a DMS migration job with full dump plus change data capture, and monitor replication lag until it stays under a few seconds at peak.
Application and performance validation
Point a staging copy of the application at the target, replay production queries, and compare p95 latency and plan choices against the source.
Cutover and promotion
Freeze writes, let DMS drain the final changes, promote the target, switch connection strings via Secret Manager and keep the source read-only for rollback.
Cross-region recovery rehearsal
Promote the asia-south2 replica or secondary cluster in a test window and record actual RPO and RTO for the runbook.
What you receive
Securing Managed Databases: Private IP, IAM Database Authentication and CMEK
Database threats on Google Cloud concentrate on network exposure and credentials: instances with public IPs and broad authorised networks, application passwords in environment variables, and backups readable by too many principals. NTSPL deploys instances on private IP or Private Service Connect only, switches applications to IAM database authentication through connectors, encrypts with customer-managed keys held in India, and restricts backup and export permissions to a break-glass group.
- IAM database authentication so database access is granted and revoked through IAM groups
- Private IP or Private Service Connect only, enforced by the sql.restrictPublicIp organization policy
- CMEK with Cloud KMS keys in asia-south1 and asia-south2 for instances, backups and replicas
- Data Access audit logs on Cloud SQL and AlloyDB administrative and data operations for CERT-In log retention needs
- VPC Service Controls around database projects to block export of backups to external buckets
Database Pricing Levers: vCPU and Node Sizing, Editions, Read Pools and Committed Use
Cloud SQL and AlloyDB bill per vCPU-hour and GB-hour of memory for each instance, plus storage, backups and network egress; HA doubles primary compute in Cloud SQL. Spanner bills compute in nodes or processing units per hour by edition and configuration, plus storage per GB-month. Firestore bills per document read, write and delete. Over-provisioned HA standbys and idle replicas are the usual waste.
- Committed use discounts on Cloud SQL, AlloyDB and Spanner for steady production instances after one month of sizing data
- AlloyDB read pools scaled to reporting hours instead of permanently oversized primaries
- Spanner managed autoscaler on processing units so capacity follows daily traffic rather than peak
- Memorystore caching of hot keys to cut primary vCPU by 20-40% on read-heavy services
- Enterprise edition, not Enterprise Plus, for non-production and internal databases
Cloud SQL vs AlloyDB vs Spanner: which Google Cloud database should I choose?
Decide on four criteria. Engine: Cloud SQL supports MySQL, PostgreSQL and SQL Server; AlloyDB is PostgreSQL only; Spanner offers GoogleSQL and a PostgreSQL interface with some differences from native PostgreSQL. Write scale: Cloud SQL and AlloyDB scale writes vertically on one primary, while Spanner shards writes horizontally with no ceiling you are likely to hit. Analytics on live data: AlloyDB's columnar engine accelerates reporting queries without a separate warehouse; Cloud SQL does not. Availability: Cloud SQL Enterprise Plus and AlloyDB offer 99.99% regional SLAs, while Spanner Enterprise Plus in dual-region-india1 offers 99.999% with synchronous replication between Mumbai and Delhi. Cost rises roughly in that order, so choose the lowest tier that meets your write and availability needs.
Key facts about databases on Google Cloud
Databases on Google Cloud in Practice
3 databases scenarios from Urban mobility and ride-hailing, Healthcare (outpatient clinics), Fintech (rewards and loyalty): the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Ride-hailing platform moves trip and payments ledger to Spanner with zero data loss
Clinic network's EMR on AlloyDB serves doctors and reports from one database
Loyalty fintech handles festive redemption peaks on Cloud SQL with Memorystore
Home-services marketplace cuts missed appointments 42% with Cloud Tasks reminders
Pharmacy chain exposes e-prescription APIs and live stock across 720 stores
Databases on Google Cloud: Frequently Asked Questions
How much does Spanner cost compared with Cloud SQL for a small workload?
Spanner can start well below one node by provisioning processing units, where 1,000 processing units equal one node, so small regional databases are no longer prohibitively expensive. However, a dual-region-india1 configuration requires Enterprise Plus edition and replicates data across regions, so it costs considerably more than a Cloud SQL HA instance. We model both on your actual TPS and storage before recommending.
Can Database Migration Service move our Oracle database to PostgreSQL?
Yes. DMS supports heterogeneous migrations from Oracle to Cloud SQL for PostgreSQL and AlloyDB, using conversion workspaces to translate schema and PL/SQL code, with Gemini-assisted conversion for objects that rules cannot handle. Data then replicates continuously until cutover. Expect most effort in stored procedures and application SQL; we size it from the conversion report before committing to a date.
Which Google Cloud databases can keep all data within India?
Cloud SQL, AlloyDB, Firestore and Memorystore can all be deployed in Mumbai (asia-south1) or Delhi (asia-south2), and Spanner offers the dual-region-india1 configuration spanning both. Backups, replicas and CMEK keys must also be pinned to India locations. This matters for RBI payment data storage requirements, IRDAI record-keeping and personal data obligations under the DPDP Act 2023.
How long does a typical production database migration take?
A homogeneous MySQL or PostgreSQL migration of a few hundred gigabytes usually takes 4-6 weeks, including profiling, a rehearsal cutover and the production cutover window of 10-30 minutes. Heterogeneous Oracle or SQL Server migrations take 10-20 weeks, driven mostly by stored-procedure conversion and application testing rather than data transfer itself.
When should we use Firestore instead of Cloud SQL?
Choose Firestore when mobile or web clients need real-time listeners and offline sync, data is naturally a hierarchy of documents, and queries are key or index lookups. Choose Cloud SQL when you need joins, multi-table transactions with complex constraints, or ad hoc reporting. Firestore bills per document operation, so chatty designs that read hundreds of documents per screen become expensive quickly.
Does AlloyDB remove the need for a separate reporting database?
Often, yes, for operational reporting. The columnar engine keeps frequently queried columns in memory in columnar format and accelerates scans and aggregations, and read pools isolate reporting load from the primary. It does not replace BigQuery for multi-terabyte historical analytics or joins across many source systems; for those we stream changes from AlloyDB to BigQuery with Datastream.