Cloud Spanner Regional to Multi-Region Upgrade Strategy

PDE By islever Editorial Last updated

Designing for flexibility and portability. Selecting storage systems.

Short answer

A Use Cloud Spanner to configure a single region instance initially, and then configure multi-region Cloud Spanner instances after securing funding.

Question

Your startup has a web application that currently serves customers out of a single region in Asia. You are targeting funding that will allow your startup to serve
customers globally. Your current goal is to optimize for cost, and your post-funding goal is to optimize for global presence and performance. You must use a native
JDBC driver. What should you do?
  1. Use Cloud Spanner to configure a single region instance initially, and then configure multi-region Cloud Spanner instances after securing funding. Correct Answer
  2. Use a Cloud SQL for PostgreSQL highly available instance first, and Bigtable with US, Europe, and Asia replication after securing funding.
  3. Use a Cloud SQL for PostgreSQL zonal instance first, and Bigtable with US, Europe, and Asia after securing funding.
  4. Use a Cloud SQL for PostgreSQL zonal instance first, and Cloud SQL for PostgreSQL with highly available configuration after securing funding.

Key Takeaways

The key trap is confusing Cloud SQL HA with global scalability; HA only ensures redundancy within a region, whereas Spanner multi-region provides true global distribution.

This question tests the ability to design a cost-effective yet globally scalable database architecture using Cloud Spanner's regional and multi-region instance types.

Common mistake: Choosing Option D (Cloud SQL HA) is a common mistake because it seems like a direct upgrade path from a zonal instance. However, Cloud SQL cannot natively provide the global presence and performance required for a worldwide user base.

Expert Analysis

The scenario presents a two-phase architecture strategy constrained by the requirement for a native JDBC driver. This constraint immediately eliminates NoSQL options like Bigtable (Options B and C), which do not support JDBC natively, leaving only relational database services: Cloud Spanner and Cloud SQL.

The deciding factor is the post-funding goal: optimizing for "global presence and performance." Cloud SQL for PostgreSQL offers High Availability (HA) configurations, but these are limited to a single region (typically across two zones). They do not provide active-active global replication or low-latency access for users worldwide without complex external sharding or read-replica setups that still lack the unified global namespace of Spanner. In contrast, Google Cloud Spanner is designed specifically for horizontal scaling across multiple regions with strong consistency. It supports both regional instances (cheaper, lower latency within one region) and multi-region instances (global presence, higher cost).

Option A correctly leverages this flexibility. Starting with a single-region Spanner instance satisfies the initial cost optimization goal while maintaining the required JDBC compatibility. Upon securing funding, the instance can be upgraded to a multi-region configuration to achieve the global presence and performance objectives without migrating to a different database engine. Option D fails because upgrading Cloud SQL to HA does not solve the global latency or scalability issues inherent in a single-region service.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When evaluating database choices for global reach, always distinguish between High Availability (redundancy within a region) and Global Distribution (latency and data locality across regions). If the requirement explicitly mentions 'global presence' or 'worldwide performance,' avoid single-region RDBMS solutions like Cloud SQL and look for distributed SQL databases like Spanner that support seamless scaling from regional to multi-region topologies.

Frequently Asked Questions

Why can't I use Cloud SQL for PostgreSQL for global presence?

Cloud SQL HA configurations are limited to a single region (across zones). They do not offer active-active global replication or the low-latency global access provided by Spanner multi-region instances.

Does Cloud Spanner support JDBC drivers?

Yes, Cloud Spanner provides a native JDBC driver, making it compatible with applications that require standard SQL connectivity over JDBC.

More PDE FAQ →

Community Votes

D
53%
A
47%

53% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 22 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 22

  1. AWSandeep 👍 11 Answered A
    A. Use Cloud Spanner to configure a single region instance initially, and then configure multi-region Cloud Spanner instances after securing funding. When you create a Cloud Spanner instance, you must configure it as either regional (that is, all the resources are contained within a single Google Cloud region) or multi-region (that is, the resources span more than one region). You can change the instance configuration to multi-regional (or global) at anytime.
  2. odacir 👍 7 Answered A
    B and C has no sense because of the driver. D looks like a good option, but HA it's not to improve performance or global presence: The purpose of an HA configuration is to reduce downtime when a zone or instance becomes unavailable. This might happen during a zonal outage, or when an instance runs out of memory. With HA, your data continues to be available to client applications. So the best option is A.
  3. MaxNRG 👍 6 Answered A
    A - This option allows for optimization for cost initially with a single region Cloud Spanner instance, and then optimization for global presence and performance after funding with multi-region instances. Cloud Spanner supports native JDBC drivers and is horizontally scalable, providing very high performance. A single region instance minimizes costs initially. After funding, multi-region instances can provide lower latency and high availability globally. Cloud SQL does not scale as well and has higher costs for multiple high availability regions. Bigtable does not support JDBC drivers natively. Therefore, Spanner is the best choice here for optimizing both for cost initially and then performance and availability globally post-funding.
  4. TNT87 👍 5 Answered A
    https://cloud.google.com/spanner/docs/jdbc-drivers Ans A https://cloud.google.com/spanner/docs/instance-configurations#tradeoffs_regional_versus_multi-region_configurations The last part of the question makes it easy
  5. TNT87 👍 3
    Yes Spanner is expensive , but the question expresslty states that "after securing funding you want to have a global presence" the word globally is repeatedly stated there. Answer is A.
Show 17 more comments
  1. Quevedo 👍 3 Answered A
    A is the best option. It is globally scalable and it also meets the cost goal as it says that initially it will be configurated as single region wich is cheaper than multi region.
  2. badrisrinivas9 👍 3 Answered D
    Spanner is expensive, they haven't mentioned the size of db... optimize for cost then option is Cloud SQL which cost effective and highly available in case of multi region.
  3. lucaluca1982 👍 3
    Spanner has some limitations with JDBC. Maybe the quetion wants to help us tp choose Cloud SQL
  4. ducc 👍 3 Answered A
    Spanner still support JDBC https://cloud.google.com/spanner/docs/jdbc-drivers
  5. TNT87 👍 2
    The fact that its global cloud spanner is the answer. Secondly Option D, the fact that it has to be highly avaible and multi regional its already more expensive than Cloud spanner Regional instance. https://cloud.google.com/spanner/docs/instance-configurations#tradeoffs_regional_versus_multi-region_configurations
  6. Ronn27 👍 2
    While a zonal instance is cost-effective, transitioning to a highly available Cloud SQL instance does not support global replication. Cloud SQL lacks the scalability and global presence needed for your post-funding goals. So I beleive Spanner is the right answer
  7. SamuelTsch 👍 2 Answered D
    I go to D. Cloud SQL is usually used for web application (CRM) (https://cloud.google.com/blog/topics/developers-practitioners/your-google-cloud-database-options-explained?hl=en)
  8. YorelNation 👍 2 Answered D
    Spanner is expensive can't be A Would choose D
  9. carbonscave 👍 1 Answered A
    Why A is the right move The Global End-Game: The biggest giveaway in this scenario is the ultimate goal of a "global presence" combined with the need for a "native JDBC driver" (which firmly means you need a relational database). Spanner is GCP's only fully managed relational database built specifically to scale globally with strong consistency. Avoiding the Migration Headache: If you know you have to go global later, starting with Spanner is a smart architectural move. Running it in a single region keeps your initial startup costs relatively grounded. Once the funding hits the bank, upgrading to a multi-region deployment is essentially just a configuration change. You don't have to rewrite your application's data access layer or suffer through a painful database migration. JDBC Checkbox: Spanner provides its own open-source JDBC drivers, so it drops right into your existing application code without a fuss.
  10. Ronn27 👍 1
    While a zonal instance is cost-effective, transitioning to a highly available Cloud SQL instance does not support global replication. Cloud SQL lacks the scalability and global presence needed for your post-funding goals.
  11. b2aaace 👍 1 Answered D
    Native JDBC → eliminates Bigtable (B & C) Cost optimization initially → eliminates Spanner (A) Global expansion later → Cloud SQL can add read replicas
  12. YorelNation 👍 1
    Actually maybe C as you don't really need relational database for a webapp and BigTable is super performant and highly available
  13. TNT87 👍 1
    https://cloud.google.com/spanner/docs/instance-configurations#tradeoffs_regional_versus_multi-region_configurations Ans A
  14. musumusu 👍 1
    Answer D: Cost effective transactional database Cloud SQL. Spanner is good case for data more than 30 GB
  15. tibuenoc 👍 1 Answered D
    I think is D The best for Web app is Cloud SQL, and Spanner is the best for data more than 30GB
  16. 4a8ffd7 👍 1 Answered D
    Although A is good, but concerning about the cost. Then D will be much more suitable
  17. TNT87 👍 1
    no its A

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How to establish consistent BigQuery spend?

S-grade

Triggering Airflow DAGs Reactively in Private Cloud Composer

S-grade

Bigtable Row Key Design for Time-Series Data

S-grade

Migrating Hadoop Spark Jobs to Dataproc Serverless and Cloud Storage

S-grade

← Back to PDE Study Guide