Azure customers can select newer compute options and scale resources in real time with minimal disruption to business operations. This flexibility allows you to scale capacity as demand changes, match compute and memory profiles to each workload, and test new hardware configurations before moving production workloads. Using this opportunity to improve workload performance and cost efficiency over time results in real improvements to both price and performance.
New Compute Can Change Workload Economics
A newer compute generation is not merely a different SKU name. Changes in processor architecture, clock speed, memory bandwidth, storage throughput, and virtualization can materially affect application performance.
Azure Database for PostgreSQL offers multiple options across General Purpose and Memory Optimized tiers. Customers can change the compute size and move between hardware generations without rebuilding the database platform. Reviewing these options regularly ensures that workloads are optimized and able to maximize performance and cost investments. A workload that was appropriately sized when deployed may no longer be running on the most cost-effective infrastructure. Periodic evaluation of newer compute generations can reveal opportunities to improve throughput, latency, or capacity without increasing spend. The opportunity to upgrade Azure Postgres workloads while maintaining the same operating costs presents a valuable option for anyone currently consuming V3 family compute.
Take advantage of these capabilities by scaling your Azure Postgres workloads today: Scale Compute in Azure Database for PostgreSQL Flexible Server – Azure Database for PostgreSQL | Microsoft Learn
Benchmarking V3 and V5 PostgreSQL Compute
To measure the potential impact, we compared two Azure Database for PostgreSQL servers. Each server was provisioned with 4 General Purpose vCores, 16 GiB memory, and SSD Storage with 7500 IOPS. We ran the same CPU-intensive workload under identical test conditions with increasingly concurrent client workloads. Across repeated test runs, the V5 server processed approximately 40% more transactions than the comparable V3 configuration at effectively the same price. Benchmark resources and provisioning steps are included in the appendix.
(Higher is better)
The result represents approximately 40% more transaction throughput for the same spend in this specific benchmark.
(Lower is better)
The V5 configuration completed the workload in less time, indicating lower overall execution latency in this benchmark. For CPU-intensive workloads, this improvement translates to higher transaction volumes, reduced processing backlogs and latency, and provides additional capacity for future growth at approximately the same cost.
Database performance also depends on memory, storage, I/O latency, concurrency, query design, indexing, PostgreSQL configuration, and application behavior. This result should therefore be treated as a workload-specific reference benchmark rather than a universal performance claim. The most meaningful comparison is one performed with a representative version of your own workload.
Infrastructure should be reviewed continuously
Cloud optimization is not a one-time sizing exercise. A server selected several years ago may continue to operate reliably while missing newer price-performance improvements. Regular infrastructure reviews help teams identify opportunities before older choices become unnecessary cost or capacity constraints.
Teams should periodically review:
- Available compute family options in their Azure regions
- CPU, memory, storage, and I/O utilization
- Current and projected workload demands
- Transactions or queries completed per unit of cost
- Performance under representative load
- Migration requirements and expected downtime
For additional guidance on optimizing Azure Database for PostgreSQL workloads, see Plan Azure Database for PostgreSQL flexible server deployments for operational performance on Microsoft Learn.
Azure’s continued investment in regions, datacenters, and compute infrastructure gives customers new ways to improve their workloads. Realizing that value requires regularly reviewing what has become available, measuring it against real application behavior, and adopting it where the business case makes sense.
The combination of continued platform investment from Microsoft and your active optimization becomes an ongoing partnership focused on helping your businesses perform, scale, and succeed.
Appendix
This appendix provides the resources and provisioning steps used for the benchmark.
Benchmark Resources
The benchmark was deployed using the following bicep file definition, named “postgres-flex-compute-benchmarks.bicep”:
param administratorLogin string = ‘benchAdmin’
@secure()
param administratorLoginPassword string = ”
param serverEdition string = ‘GeneralPurpose’
type serverConfiguration = {
serverName: string
skuName: string
}
param storageSizeGB int = 32
param storageTier string = ‘P40’ //7500 IOPS
param location string = ‘canadacentral’
param haMode string = ‘Disabled’
param availabilityZone string = ‘2’
param serverConfigs serverConfiguration[] = [
{
serverName: ‘bench-standard-d4s-v3’
skuName: ‘Standard_D4s_v3’ // 4 vCores, 16 GiB memory, 6400 Max IOPS
}
{
serverName: ‘bench-standard-d4s-v5’
skuName: ‘Standard_D4s_v5’ // 4 vCores, 16 GiB memory, 6400 Max IOPS
}
]
resource servers ‘Microsoft.DBforPostgreSQL/flexibleServers@2025-08-01’ = [for serverConfig in serverConfigs: {
location: location
name: serverConfig.serverName
properties: {
createMode: ‘Default’
version: ’18’
administratorLogin: administratorLogin
administratorLoginPassword: administratorLoginPassword
availabilityZone: availabilityZone
storage: {
storageSizeGB: storageSizeGB
autoGrow: ‘Disabled’
type: ‘Premium’
tier: storageTier
}
network: {
publicNetworkAccess: ‘Enabled’
}
backup: {
backupRetentionDays: 7
geoRedundantBackup: ‘Disabled’
}
highAvailability: {
mode: haMode
}
}
sku: {
name: serverConfig.skuName
tier: serverEdition
}
}]
// Create the firewall rule on every server.
resource serverFirewallRules ‘Microsoft.DBforPostgreSQL/flexibleServers/firewallRules@2025-08-01’ = [
for (serverConfig, i) in serverConfigs: {
name: ‘AllowAll’
parent: servers[i]
properties: {
startIpAddress: ‘0.0.0.0’
endIpAddress: ‘255.255.255.255’
}
}
]
The following plpgsql function was created to prioritize CPU operations:
CREATE OR REPLACE FUNCTION leibniz_pi(iterations integer)
RETURNS double precision
LANGUAGE plpgsql
AS $$
DECLARE
i integer;
result double precision := 0;
sign double precision := 1;
BEGIN
FOR i IN 0..iterations – 1 LOOP
result := result + sign / (2 * i + 1);
sign := -sign;
END LOOP;
RETURN 4 * result;
END;
$$;
Provisioning Steps
- Provision two Azure Database for PostgreSQL flexible servers using comparable V3 and V5 compute configurations using the following CLI command:
$password = Read-Host “Password” -MaskInput
az deployment group create `
–resource-group <your_resource_group_name> `
–template-file ./postgres-flex-compute-benchmarks.bicep `
–parameters administratorLoginPassword=”$password” - Once the servers have been provisioned, create the “leibniz_pi” function on each server.
- Use containerized environments to execute a pgbench while passing in the custom plpgsql function:
‘SELECT leibniz_pi(10000000);’ |
docker run –rm -i `
-e PGPASSWORD=”<YOUR_PG_PASSWORD>” `
postgres:18 `
pgbench -n -c 8 -j 8 -T 300 -f – `
“host=<V3_OR_V5_SERVER_NAME>.postgres.database.azure.com port=5432 dbname=postgres user=benchAdmin sslmode=require” - Repeat the test runs and record transaction throughput, execution time, and relevant resource metrics.
- Compare the results while accounting for workload variability and any differences in the underlying compute architecture.