Cloud SQL for SQL Server now provides C4D machine types for Enterprise Plus instances. C4D is based on 5th Generation AMD EPYC processors and uses Google Cloud Hyperdisk Balanced storage. The available sizes range from 2 vCPUs and 15 GB memory up to 192 vCPUs and 1,512 GB memory.
For a SQL Server workload that is already running in Cloud SQL, moving to C4D is not simply a matter of selecting a larger VM. The machine series changes the underlying compute and storage characteristics, and in some cases the Cloud SQL edition must also change.
This makes the migration worth planning rather than treating it as an ordinary resize.
The good part is that Cloud SQL supports changing the machine type in place. Google documents C4D as a supported machine series for Cloud SQL for SQL Server Enterprise Plus instances, so you can move an eligible instance without building a completely new database environment just to change the machine series.
The important question is not only whether C4D is faster.
The real question is whether your SQL Server workload will benefit from the combination of CPU, memory, Hyperdisk Balanced storage, and the C4D machine configuration without introducing an unexpected storage or operational change.
What Is the C4D Machine Series?
C4D is a Cloud SQL machine series designed for high-demand workloads.
It uses 5th Generation AMD EPYC processors, also known as Turin, together with Google Titanium infrastructure. Cloud SQL uses Hyperdisk Balanced as the storage option for C4D.
The available Cloud SQL for SQL Server C4D machine types currently include:
Machine type | vCPUs | Memory |
|---|
db-perf-optimized-C4D-2 | 2 | 15 GB |
db-perf-optimized-C4D-4 | 4 | 31 GB |
db-perf-optimized-C4D-8 | 8 | 63 GB |
db-perf-optimized-C4D-16 | 16 | 126 GB |
db-perf-optimized-C4D-32 | 32 | 252 GB |
db-perf-optimized-C4D-48 | 48 | 378 GB |
db-perf-optimized-C4D-64 | 64 | 504 GB |
db-perf-optimized-C4D-96 | 96 | 756 GB |
db-perf-optimized-C4D-192 | 192 | 1,512 GB |
Availability depends on the Cloud SQL edition, database version, and region.
This range is useful because C4D is not only an option for very large databases. A smaller C4D configuration can also make sense when the workload needs a different compute or storage profile without immediately increasing the database to hundreds of vCPUs.
Why Move an Existing SQL Server Workload to C4D?
There are several reasons an organization might consider the move.
The first is CPU performance.
A SQL Server workload with sustained CPU pressure may benefit from a newer processor platform. This is especially relevant for workloads involving frequent joins, sorting, aggregation, stored procedures, reporting queries, or other CPU-heavy operations.
The second reason is memory.
A larger C4D machine provides more memory as the vCPU count increases. If the SQL Server working set is larger than the current instance can comfortably hold, increasing memory can reduce pressure on storage.
The third reason is storage performance.
C4D uses Hyperdisk Balanced rather than the SSD storage used by older N2 and general-purpose machine families. Hyperdisk Balanced allows configurable IOPS and throughput within the limits of the selected machine configuration.
The fourth reason is consolidation.
Instead of running several smaller database instances, an organization may be able to move a demanding workload to a larger C4D configuration when the application architecture supports it.
However, the decision should come from workload measurements rather than the machine family name.
C4D Is Not Just a CPU Upgrade
This is one of the most important points when planning the migration.
A traditional resize might look like:
Current instance
↓
More vCPUs / more memory
↓
Same basic storage model
Moving to C4D can instead involve:
Existing machine series
↓
Enterprise Plus
↓
C4D machine type
↓
Hyperdisk Balanced
↓
New IOPS / throughput configuration
Google documents that changing from an older SSD-backed machine series to C4D can migrate the storage to Hyperdisk Balanced. This can result in some downtime and a change in storage costs.
Therefore, storage behavior must be included in the migration plan.
Check the Current Cloud SQL Edition First
C4D is available for Cloud SQL Enterprise Plus.
If the current SQL Server instance is already using Enterprise Plus, the machine change is more straightforward.
If the instance is running Cloud SQL Enterprise, you need to evaluate an edition upgrade before moving to C4D.
Google documents that Cloud SQL Enterprise Plus supports N2, Memory-optimized N2, C4, and C4D machine series, while Cloud SQL Enterprise uses general-purpose dedicated-core and N4 machine series.
Check the current instance before planning the change.
For example:
gcloud sql instances describe INSTANCE_NAME
Review the returned configuration for the current edition and machine configuration.
Do not assume that an Enterprise instance can simply be changed to a C4D machine type.
Check Regional Availability
Machine series availability is regional.
This is particularly important for production databases because moving an application to a different region just to obtain a machine type can create a much larger architectural change than the database resize itself.
As of the current Cloud SQL documentation, C4D is available in selected regions, including regions such as Tokyo, London, Frankfurt, Paris, Northern Virginia, and South Carolina. Availability can change, so check the current regional availability before planning a production migration.
For example, an organization running in a region without C4D should not assume that the machine type will appear in the Cloud Console.
Measure the Existing Workload Before Changing Anything
Do not start with:
Current: 16 vCPU
Target: 32 vCPU C4D
Start with:
What is limiting the current workload?
Collect measurements such as:
The goal is to identify the bottleneck.
For example:
CPU 85%
Memory 45%
Storage latency low
suggests a different problem from:
CPU 40%
Memory 95%
Storage latency high
Both workloads may be described as "slow SQL Server," but they require different solutions.
Check SQL Server Memory Behavior
SQL Server uses memory aggressively for caching data and execution-related structures.
A workload with insufficient memory may repeatedly read pages from storage.
Conceptually:
Without enough memory:
Query
↓
SQL Server memory
↓
Page not available
↓
Storage read
↓
Higher latency
With enough memory:
Query
↓
SQL Server memory
↓
Cached page
↓
Lower storage dependency
Increasing memory can therefore improve performance even if CPU usage is not particularly high.
However, do not assume that every workload needs the largest C4D machine. SQL Server memory requirements should be measured against the database working set and concurrent workload.
Google also recommends load testing and ensuring sufficient memory for real-time processing workloads such as OLTP.
Understand Hyperdisk Balanced Before the Move
Hyperdisk Balanced is an important part of C4D.
The storage service separates capacity from performance more clearly than traditional storage configurations.
You can configure:
Storage capacity
Provisioned IOPS
Provisioned throughput
The available limits depend on the C4D machine type.
For example, the documented maximum Hyperdisk Balanced limits for C4D vary by machine size.
A 16-vCPU C4D configuration can support substantially more provisioned IOPS and throughput than a 2-vCPU configuration.
This means that selecting a C4D machine should not be based only on CPU and memory.
Think about the complete resource profile:
C4D selection
├── vCPU
├── Memory
├── IOPS
├── Throughput
└── Storage capacity
The database workload determines which combination makes sense.
Data Cache Is Not Supported on C4D
This is an easy migration detail to miss.
Cloud SQL does not support data cache for C4D machine types. Google specifically notes that if an existing instance has data cache enabled and you change it to C4D, you must disable the data cache.
For the gcloud CLI, this can require:
gcloud sql instances patch INSTANCE_NAME \
--no-enable-data-cache
The exact command should be validated against the current Cloud SQL CLI documentation and your instance configuration before production execution.
Do not treat this as a minor configuration detail.
If your existing workload depends heavily on the behavior of data cache, benchmark the C4D configuration after the change.
Plan the Machine Change
Once the workload and target configuration are known, the migration can be planned as an in-place machine change.
The basic process is:
1. Measure current workload
↓
2. Verify Enterprise Plus eligibility
↓
3. Verify C4D regional availability
↓
4. Select target C4D size
↓
5. Plan Hyperdisk settings
↓
6. Disable unsupported data cache if required
↓
7. Test application behavior
↓
8. Schedule the production change
↓
9. Change machine type
↓
10. Validate workload
This is different from a database migration where data is copied to another instance.
The in-place approach keeps the database instance identity and configuration within the same Cloud SQL instance while changing its infrastructure.
Google describes in-place infrastructure changes as the most direct way to reconfigure a Cloud SQL instance.
Understand the Downtime
A machine change is not necessarily a zero-downtime event.
Google documents that moving to Hyperdisk Balanced can involve some downtime, although the storage migration generally requires minimal downtime.
The actual operational impact depends on the specific change and instance configuration.
For a production database, treat the operation as a maintenance event.
Plan for:
Application traffic
↓
Maintenance window
↓
Cloud SQL infrastructure change
↓
Database available
↓
Application reconnect
↓
Validation
↓
Normal traffic
Do not tell application teams that the change is guaranteed to be invisible.
Instead, test connection retry and connection-pool recovery before production.
Make the Application Tolerate Database Reconnection
Even a short database interruption can affect an application.
A .NET application should not assume that a SQL Server connection will remain valid indefinitely.
Connection pools may contain connections that become unusable during maintenance.
Use normal SQL Server connection retry behavior where appropriate.
For example, with Microsoft.Data.SqlClient:
var builder = new SqlConnectionStringBuilder(connectionString)
{
ConnectRetryCount = 5,
ConnectRetryInterval = 5
};
await using var connection =
new SqlConnection(builder.ConnectionString);
await connection.OpenAsync();
This does not make every database operation automatically safe.
Transactions, writes, and commands that fail after execution begins still need application-level handling.
The important goal is to make normal connection establishment resilient to short infrastructure interruptions.
Test the C4D Configuration Before Production
A production database should not be your first benchmark.
If the workload is important, create a representative test environment and compare the current configuration against the target.
The test should include:
Current machine
↓
Representative database
↓
Production-like workload
Target C4D machine
↓
Same database/data profile
↓
Same workload
Measure:
Average query latency
P95 latency
P99 latency
Transactions per second
CPU utilization
Memory pressure
Storage latency
IOPS
Throughput
Batch completion time
Connection behavior
Do not rely on one synthetic query.
A database workload is a mixture of queries, concurrency, background jobs, maintenance tasks, and application traffic.
Compare Query Plans
Changing infrastructure does not automatically change SQL Server query plans in a predictable way.
A slow query may remain slow because the underlying problem is:
For example:
SELECT *
FROM Orders
WHERE CustomerId = @CustomerId;
If CustomerId is not properly indexed, adding more CPU does not necessarily solve the underlying problem.
Use C4D to address infrastructure bottlenecks, not as a substitute for query tuning.
Check Storage-Heavy Queries
C4D's Hyperdisk Balanced storage can be configured for IOPS and throughput within machine-specific limits.
That makes storage benchmarking particularly important.
Look for workloads such as:
Large table scans
Heavy reporting queries
Bulk imports
ETL jobs
Index maintenance
Large sorts
TempDB-heavy operations
A workload that spends most of its time waiting on storage may benefit differently from a workload that spends most of its time executing CPU-intensive expressions.
Measure first.
Choose the C4D Size Based on the Workload
Suppose the existing database has:
16 vCPU
128 GB memory
Do not automatically select a 32-vCPU C4D configuration because it is the next larger number.
C4D provides specific vCPU-to-memory ratios.
For example:
C4D-16
16 vCPU
126 GB memory
C4D-32
32 vCPU
252 GB memory
C4D-64
64 vCPU
504 GB memory
The target should be selected based on measured CPU, memory, and storage requirements.
A useful decision process is:
CPU constrained?
↓
Increase compute capacity
Memory constrained?
↓
Select a machine with sufficient memory
Storage constrained?
↓
Review Hyperdisk IOPS/throughput
All three constrained?
↓
Evaluate larger C4D configuration
This prevents overprovisioning.
Check Licensing and Edition Requirements
SQL Server licensing and Cloud SQL edition are separate considerations.
C4D availability is tied to Cloud SQL Enterprise Plus, which changes the service configuration and pricing model compared with Enterprise.
Before approving the move, calculate the total operating cost:
Compute
+
Cloud SQL edition
+
Storage capacity
+
Provisioned IOPS
+
Provisioned throughput
+
Backup/storage
+
Other service costs
A faster database that costs significantly more may still be justified for a business-critical workload, but that should be a measured decision.
Monitor After the Migration
Do not end the migration when the Cloud Console reports that the instance is running.
The real validation begins after the change.
Monitor:
CPU
Memory
Query latency
Query throughput
Storage IOPS
Storage throughput
Connection count
Wait events
Error rate
Application latency
Batch duration
Compare these metrics against the pre-migration baseline.
For example:
Before:
P95 query latency = 180 ms
After:
P95 query latency = 95 ms
That is useful evidence.
Likewise:
Before:
CPU = 85%
After:
CPU = 48%
suggests that the new machine configuration has additional compute headroom.
But if CPU decreases while storage latency increases, the bottleneck may simply have moved.
Have a Rollback Plan
A migration plan should include what happens if the new configuration performs worse.
Cloud SQL supports changing machine types again, but moving between storage families can have different downtime characteristics. Google specifically notes that moving from Hyperdisk Balanced back to SSD can incur significant downtime.
That means rollback should not be treated as:
C4D
↓
Click previous machine
↓
Everything instantly returns to normal
Instead, document:
Previous machine type
Previous storage configuration
Data cache configuration
Application maintenance procedure
Expected downtime
Validation steps
Escalation contact
Decision criteria for rollback
If the target C4D configuration is acceptable but a query regression exists, fixing the query may be safer than immediately reversing the infrastructure change.
When an In-Place Change Is Not the Best Option
An in-place machine change is attractive when the goal is simply to change infrastructure.
There are cases where creating another instance makes more sense.
For example:
Current production
│
├── Application traffic
│
▼
New C4D instance
│
├── Test workload
├── Validation
└── Cutover
A separate environment provides more isolation for testing.
It can also make sense when you are changing multiple dimensions at once, such as:
Cloud SQL Database Migration Service supports migrations between Cloud SQL for SQL Server instances, including moving to a later major SQL Server version with minimal downtime.
If the project is larger than a machine change, a side-by-side migration may be easier to control.
Common Mistakes
Treating C4D as only a CPU upgrade
C4D also changes the storage architecture to Hyperdisk Balanced.
Include storage performance in the benchmark.
Forgetting the Enterprise Plus requirement
C4D is part of Cloud SQL Enterprise Plus.
Check the current edition before designing the migration.
Ignoring data cache
C4D does not support data cache.
If the current instance uses it, plan the configuration change explicitly.
Choosing the largest machine
More vCPUs are not automatically better.
An oversized instance can increase cost without fixing the actual bottleneck.
Testing only CPU
SQL Server performance depends on CPU, memory, storage, concurrency, locking, query plans, and workload behavior.
Benchmark the complete workload.
Assuming no downtime
Infrastructure changes can interrupt database connectivity.
Plan application reconnection and a maintenance window.
Having no rollback criteria
Define in advance what constitutes a failed migration.
For example:
Rollback if:
P99 latency > baseline × 1.5
for 30 consecutive minutes
and no application-side cause is identified.
The exact threshold should come from the application's service-level objectives.
Production Migration Checklist
Before moving a Cloud SQL for SQL Server workload to C4D, verify:
The instance uses Cloud SQL Enterprise Plus.
C4D is available in the required region.
The SQL Server version is supported.
Current CPU utilization has been measured.
Current memory pressure has been measured.
Storage latency has been measured.
IOPS and throughput requirements are understood.
The target C4D machine type has enough CPU and memory.
Hyperdisk Balanced settings have been reviewed.
Data cache usage has been checked.
Data cache is disabled when required.
Application connection retry behavior has been tested.
A representative workload has been benchmarked.
Query plans have been reviewed for major queries.
Expected maintenance impact has been communicated.
A rollback procedure has been documented.
Cost has been compared before and after the move.
Post-migration monitoring is ready.
Application performance will be compared against the baseline.
Advantages and Disadvantages
Moving to C4D can provide a better fit for demanding SQL Server workloads, especially when the workload benefits from newer compute and Hyperdisk Balanced storage.
Advantages include:
Newer AMD EPYC processor platform
Large range of available machine sizes
High memory capacity on larger configurations
Hyperdisk Balanced storage
Configurable storage IOPS and throughput
In-place machine changes
Suitable for high-demand Cloud SQL workloads
Predictable machine configurations
There are also tradeoffs:
C4D requires Cloud SQL Enterprise Plus
C4D does not support data cache
Moving from SSD to Hyperdisk Balanced changes storage behavior
Machine and storage changes can involve downtime
Larger configurations can increase cost significantly
Performance improvements depend on the actual workload
Some workloads may be limited by SQL query design rather than infrastructure
Summary
Moving a SQL Server workload in Cloud SQL to C4D is primarily an infrastructure optimization exercise, not a database rewrite.
C4D provides Cloud SQL Enterprise Plus instances with 5th Generation AMD EPYC processors and Hyperdisk Balanced storage. It currently scales from 2 vCPUs and 15 GB memory to 192 vCPUs and 1,512 GB memory, depending on region and configuration.
The migration can be performed in place when the instance is eligible, but the storage change must be understood. Moving from older SSD-backed machine series to C4D changes the storage layer to Hyperdisk Balanced and can affect downtime, storage cost, IOPS, and throughput configuration. C4D also does not support data cache.
The safest approach is to measure the current workload first, identify the actual bottleneck, select the smallest C4D configuration that provides the required capacity, test the workload, prepare the application for reconnection, and validate performance after the change.
If the workload is CPU-bound, memory-constrained, or limited by storage performance, C4D can be a useful next step. If the real problem is an inefficient query, missing index, blocking, or poor application behavior, changing the machine will not remove the underlying problem.
Join the conversation! Your thoughts help the community grow.