I ran 1,852 cloud provisioning tests. GCP takes twice as long as AWS to spin up a Postgres database.

I've been running automated provisioning benchmarks across AWS, Azure, and GCP for over a year. Every few hours, a script provisions a fresh managed PostgreSQL instance on each cloud, waits until it's actually accepting connections, records the time, then tears it down.

No marketing numbers. No theoretical limits. Just real API calls, wall-clock time, and 1,852 completed test runs across 9 regions.

Here's what I found.

The numbers

p50 = median. p95 = 95th percentile. All times in seconds.

What jumped out

GCP Cloud SQL is consistently 2x slower than AWS RDS

AWS provisions in ~5 minutes at median. GCP takes ~10 minutes. Every time. Across all three regions I test.

This isn't a fluke or a bad day — it's the baseline. GCP Cloud SQL instances are healthy when they come up, they just take significantly longer to become available.

For one-off provisioning this is barely noticeable. For pipelines that spin up ephemeral databases — CI/CD environments, test isolation, staging automation — a 6-minute penalty per instance compounds fast.

AWS RDS hit 100% success across 619 runs

Not 99.9%. Not 99.5%. 100.0%.

Zero failures across us-east-1, us-west-2, and eu-north-1 over the entire dataset. That's a genuinely impressive reliability record for an operation that involves storage allocation, network config, parameter group application, and backup initialization all happening in sequence.

Azure fails roughly 1 in 25 attempts

Azure Database for PostgreSQL runs at 95.6–96.1% success rate. That's ~4% failure rate, or about 1 in 25 attempts.

The failures are typically transient and succeed on retry. But if you're running Terraform without retry logic, you'll hit these. Worth building lifecycle retry blocks or a wrapper script if you're on Azure.

Interesting counterpoint: Azure northeurope at 289s p50 is actually the fastest single region in the entire dataset — faster than all three AWS regions. Speed isn't Azure's problem. Reliability is.

Watch the p95 numbers, not just p50

The gap between p50 and p95 tells you how predictable a cloud is.

AWS us-east-1: p50 is 305s, p95 is 334s. Gap of ~30 seconds. You can write a Terraform timeout with confidence.

GCP us-east1: p50 is 625s, p95 is 743s. Gap of ~2 minutes. And the p95 destroy time in us-west2 hits 684 seconds — longer than it takes AWS to provision. That's a long time to wait for a teardown in a CI pipeline.

Azure eastus2 has the widest provision spread: p50 of 331s but p95 of 451s, a 2-minute gap.

How the tests work

Each test run:

1. Calls the cloud provider API via Terraform to create a managed PostgreSQL instance


2. Polls until the provider signals the instance is available (accepting connections)


3. Records wall-clock time from API call to availability


4. Issues destroy and records teardown time


5. Pushes results to a central PostgreSQL database

Instance config is kept consistent: single-node, general-purpose instance class, 20GB SSD, no read replicas. Tests run 24/7 on a rotating schedule to capture time-of-day variance.

Everything is tagged piq-d1-* and destroyed immediately. No data is written to the test instances.

Live data

This is part of .

Full write-up with more context: How Long Does It Actually Take to Provision a PostgreSQL Database on AWS, Azure, and GCP?

What's next

I'm tracking VM provisioning (V1) and serverless containers (C1) with the same methodology — cross-workload comparisons are on the roadmap.

Next up for databases: Aurora PostgreSQL, AlloyDB, and Azure HorizonDB (D2). Curious whether the premium tiers are actually faster to provision or just faster once running.

Would be curious if anyone else has instrumented provisioning times in their own pipelines — do these numbers match what you're seeing?

Tags: cloud, aws, azure, googlecloud, devops