How Long Does It Actually Take to Provision a PostgreSQL Database on AWS, Azure, and GCP?
We ran 1,852 synthetic tests across 9 regions to find out — and the results surprised us.
Cloud providers make provisioning look effortless in their marketing. Click a button, wait a moment, and your managed PostgreSQL database is ready. But how long does it actually take? And more importantly — is that time consistent, or does it vary wildly depending on when and where you provision?
I’ve been running continuous synthetic provisioning benchmarks across AWS RDS, Azure Database for PostgreSQL, and GCP Cloud SQL since early 2025. Every few hours, an automated runner provisions a fresh managed PostgreSQL instance in each of three regions per cloud, measures the time from API call to database-available, then destroys it. No caching, no warm instances — just raw, real API calls every time.
After 1,852 completed test runs across 9 regions, here’s what the data shows.
The Short Answer
If provisioning speed is a priority, AWS RDS is the clear winner — provisioning a managed PostgreSQL instance in just over 5 minutes at median, with perfect 100% reliability across all three regions tested.
Azure is slightly slower but in the same general range, with one important caveat: it fails roughly 1 in 25 attempts.
GCP Cloud SQL is the outlier — taking more than double the time of AWS to provision, consistently, across all three of its tested regions.
The Data: Provision Time by Cloud and Region
All times are in seconds. p50 is the median (half of runs faster, half slower). p95 means 95% of runs completed within this time.
| Cloud | Region | Provision p50 (sec) | Provision p95 (sec) | Destroy p50 (sec) | Runs | Success % |
|---|---|---|---|---|---|---|
| AWS | eu-north-1 | 298.3 | 318.5 | 122.5 | 206 | 100.0% |
| AWS | us-east-1 | 304.7 | 333.6 | 117.6 | 207 | 100.0% |
| AWS | us-west-2 | 303.0 | 315.0 | 118.3 | 206 | 100.0% |
| Azure | eastus2 | 330.9 | 451.1 | 131.7 | 203 | 95.6% |
| Azure | northeurope | 288.6 | 338.5 | 106.3 | 207 | 95.7% |
| Azure | westus2 | 329.7 | 340.8 | 124.2 | 206 | 96.1% |
| GCP | europe-north1 | 642.1 | 760.1 | 117.3 | 205 | 100.0% |
| GCP | us-east1 | 624.7 | 743.3 | 104.6 | 206 | 95.6% |
| GCP | us-west2 | 614.9 | 757.7 | 105.1 | 206 | 100.0% |
What Stands Out
1. GCP takes more than twice as long as AWS to provision
This is the most striking finding. AWS provisions a managed PostgreSQL instance in roughly 5 minutes (298–305 seconds at median). GCP takes 10–11 minutes for the same operation. That gap is consistent — it’s not a regional anomaly or an occasional slowdown. All three GCP regions show the same pattern, every time.
To be clear: this isn’t a failure. GCP Cloud SQL instances come up healthy and functional. They just take significantly longer to become available than AWS RDS or Azure Database for PostgreSQL.
For interactive use — clicking “create” once and waiting — this difference barely matters. For automated infrastructure pipelines, Terraform-based deployments, or CI/CD workflows that spin up ephemeral databases, a consistent 6-minute penalty per instance adds up fast.
2. AWS RDS has perfect reliability
Every single AWS RDS provisioning attempt in this dataset succeeded. Across 619 runs spread across us-east-1, us-west-2, and eu-north-1, the success rate is 100.0%. That’s not a rounding artifact — there are zero recorded failures in the AWS D1 dataset.
This is notable because managed database provisioning is not a trivial operation. It involves storage allocation, network configuration, parameter group application, and backup initialization. AWS completes all of this without a hiccup, consistently.
3. Azure fails roughly 1 in 25 times
Azure Database for PostgreSQL shows a 95.6–96.1% success rate across its three tested regions. That means roughly 1 in 25 provisioning attempts fails. The failures aren’t catastrophic — most are transient and would succeed on retry — but for automated workflows, this is a meaningful reliability gap compared to AWS.
The good news for Azure: when it succeeds, it’s fast. Azure northeurope at 288.6 seconds p50 is actually the fastest single region in the entire dataset, edging out all three AWS regions. The reliability gap, not the speed, is Azure’s main weakness here.
4. p95 latency reveals hidden variance
The spread between p50 and p95 tells you how consistent a cloud is — a narrow gap means predictable behavior, a wide gap means surprises.
AWS is remarkably tight: in us-east-1, p50 is 304.7s and p95 is 333.6s — a gap of under 30 seconds. You can set a Terraform timeout with confidence.
GCP’s p95 is more concerning. In us-east1, p50 is 624.7s but p95 is 743.3s — a gap of nearly 2 minutes. In us-west2, the p95 destroy time hits 684 seconds, which is extraordinary for a teardown operation.
Azure eastus2 shows the widest provision variance: p50 of 330.9s but p95 of 451.1s, a gap of 120 seconds.
5. Destroy times tell a different story
Provisioning speed gets all the attention, but destroy time matters too — especially for ephemeral environments and cost management.
All three clouds destroy instances in roughly the same timeframe at median: 105–132 seconds (about 2 minutes). But GCP’s p95 destroy time in us-east1 is 561 seconds and in us-west2 hits 684 seconds. That’s 11 minutes to tear down an instance at the 95th percentile — longer than AWS takes to provision one.
Methodology
These tests use real cloud provider APIs — no simulation, no mocking. Each run:
- Issues a create-database API call via Terraform
- Polls until the provider signals the instance is available (accepting connections)
- Records the wall-clock time from API call to availability
- Issues a destroy call and records the teardown time
- Uploads results to a central PostgreSQL database
Instance configurations are kept consistent across clouds: single-node, general-purpose instance class, 20GB SSD storage, no read replicas. Tests run on a rotating schedule, 24 hours a day, to capture time-of-day variance.
All test resources are tagged piq-d1-* and destroyed immediately after measurement. No data is retained in the test instances.
Results vary by time of day, region load, and provider infrastructure state. These numbers represent medians and percentiles across hundreds of runs — not single measurements.
Full methodology details and live data are available at the ProvisioningIQ dashboard.
What This Means for Your Infrastructure Decisions
If you’re choosing a cloud primarily for managed PostgreSQL and provisioning speed/reliability matters:
AWS RDS is the data-backed choice. Fastest median time, tightest variance, perfect reliability in this dataset.
If you’re already on Azure:
Build retry logic into your provisioning workflows. A ~4% failure rate is manageable with one retry, but don’t assume first-attempt success.
If you’re on GCP:
Factor the 10+ minute provision time into your pipeline timeouts and expect occasional extended destroy operations. GCP Cloud SQL is a solid product — it’s just slower to stand up.
If you’re running ephemeral database environments (CI/CD, testing, staging):
The time cost of GCP is most painful here. A CI pipeline that creates a fresh database per test run will accumulate significant overhead on GCP compared to AWS.
What’s Next
This dataset covers standard managed PostgreSQL (D1 in PIQ’s taxonomy). I’m planning to extend coverage to premium managed databases — Aurora PostgreSQL, AlloyDB, and Azure’s HorizonDB — which promise faster provisioning through different architectural approaches. That data will be published here when it’s ready.
I’m also tracking VM provisioning (V1) and serverless container provisioning (C1) with similar methodology. Cross-workload comparisons are available on the live dashboard.
If you found this useful, the live data updates continuously — you can follow regional trends, spot anomalies, and track whether these numbers change over time at provisioningiq.appswireless.com.
Syed Haider is the founder of AppsWireless and creator of ProvisioningIQ, a continuous cloud infrastructure benchmarking platform.
Leave a Reply