Cloud Instance Comparison

The same shape on three clouds, and why it is not the same deal

Picking a database instance usually starts with a shape — so many vCPU, so much memory — and ends with whichever name in the provider's list is the cheapest thing above that floor. This tool does that lookup on AWS RDS, Google Cloud SQL and Azure Flexible Server at once, and adds the number those lists leave out: how many connections each one will actually let you open.

How it works

• Takes a minimum vCPU count and a minimum memory figure and finds the smallest instance meeting both, per cloud.
• Shows two larger options alongside it, so you can see what the next step up costs you in resources.
• Prints each instance's connection limit next to its shape, computed from that provider's own rule.
• Marks the smallest match explicitly, because the first row in a provider's table is rarely the one you want.

smallest match = min over instances where
    vcpu >= your_minimum  AND  memory >= your_minimum
  ordered by vcpu, then memory

connections come from each provider's published rule,
not from a shared industry default

Worked example

A service that needs at least 8 vCPU and 32 GiB, priced out across the three clouds.

1. AWS: db.m5.2xlarge — 8 vCPU, 32 GiB, about 3,324 connections
2. Azure: B8ms — 8 vCPU, 32 GiB, 3,437 connections
3. Google Cloud SQL: db-custom-8-53248 — 8 vCPU, 52 GiB, 600 connections
4. the shapes match closely on two clouds; the connection limits do not match at all

AWS and Azure land on effectively identical hardware with effectively identical connection ceilings. Cloud SQL gives you 20 GiB more memory and about a fifth of the connections. If your service is connection-heavy rather than memory-heavy, that is the whole decision.

Reading the result

• Cloud SQL accepts arbitrary custom machine shapes, so the smallest match shown for Google is the smallest in this catalogue rather than the smallest that exists. An exact 8 vCPU and 32 GiB shape is available there; the column says so, and you should read the Google figure as a sample rather than an exhaustive list.
• The smallest match is sometimes burstable, and burstable is not equivalent. Azure's B-series and AWS's t-class accumulate CPU credits when idle and throttle when the credits run out — fine for a development database or a spiky internal tool, poor for anything with a sustained floor of load.
• vCPU counts are not comparable across clouds without care. AWS Graviton instances count physical cores while x86 classes count hyperthreads, so an 8 vCPU Graviton instance and an 8 vCPU x86 instance are not the same amount of compute. Compare within a cloud confidently, across clouds only roughly.
• This compares shape and connection ceiling, not price. Reserved capacity, committed use discounts and savings plans move the real cost by large multiples, and they move it differently on each cloud, so a shape comparison is the start of a decision rather than the end of one.
• Memory matters more than vCPU for most databases, because it determines both the cache that keeps queries off disk and, on AWS and Azure, the connection ceiling itself. If you are unsure which floor to raise, raise memory.

Common questions

Why does Google show more memory than I asked for?

Because the catalogue here samples common Cloud SQL shapes rather than enumerating every possible one, and the nearest sampled shape above your floor may overshoot. Cloud SQL supports custom shapes, so you can usually request the exact memory you want — treat the Google column as indicative.

Is the smallest match always the right choice?

It is the cheapest thing that clears your floor, which is only right if the floor is right. Set the floor from measured usage plus headroom for growth and for the failover, not from current peak — an instance sized exactly to today's peak has no room for tomorrow's.

Why do the connection limits differ so much for the same memory?

Because they are set by different rules with different intentions. AWS and Azure derive the limit from memory and land in the same range. Google sets it from memory tiers with much lower values, on the assumption that connection-heavy workloads use a pooler. None of the three is wrong; they are enforced differently and that is what matters to you.