More Performance, Same Price: Azure Postgres V3 & V5 Compute Compared

As an Azure customer, you have the option to choose from the latest compute options, and you can adjust your resources in real time with hardly any impact on your business activities. This adaptability means you can increase your capacity as demand fluctuates, align your compute and memory profiles with each workload, and even test new hardware configurations before migrating production workloads. By leveraging these opportunities, you can enhance both workload performance and cost efficiency over time, leading to tangible improvements in pricing and overall performance.

Transitioning to a new compute generation involves more than just changing the SKU name. Variations in processor architecture, clock speed, memory bandwidth, storage throughput, and virtualization can significantly influence application performance.

With Azure Database for PostgreSQL, you have various options to choose from within the General Purpose and Memory Optimized tiers. The great thing is that you can change the compute size and switch between hardware generations without needing to rebuild your database platform. Regularly reviewing these options helps ensure that your workloads are optimised, allowing you to get the best performance for your investment. What worked for your initial deployment might not still be the most cost-effective solution. By periodically assessing newer compute generations, you can uncover chances to enhance throughput, reduce latency, or increase capacity without raising your costs. For anyone currently using the V3 family compute, the chance to upgrade Azure Postgres workloads while keeping operational costs the same is indeed a worthwhile option.

Don’t miss out on these capabilities—start scaling your Azure Postgres workloads today: Learn how to Scale Compute in Azure Database for PostgreSQL Flexible Server – Azure Database for PostgreSQL | Microsoft Learn

To illustrate the possible impact, we compared two Azure Database for PostgreSQL servers. Both servers were set up with 4 General Purpose vCores, 16 GiB memory, and SSD Storage featuring 7500 IOPS. We executed the same CPU-intensive workload under identical conditions with progressively concurrent client workloads. Across multiple test runs, the V5 server handled about 40% more transactions than its V3 counterpart, all at roughly the same price. For detailed information on the benchmark resources and provisioning steps, please refer to the appendix.

(Higher is better)

This result indicates an impressive 40% increase in transaction throughput for the same expenditure in this benchmark.

(Lower is better)

The V5 configuration completed tasks more quickly, signifying lower overall execution latency in this benchmark. For CPU-intensive tasks, this improvement leads to increased transaction volumes, fewer processing backlogs, and better performance—all while maintaining similar costs.

It’s important to remember that database performance is influenced by numerous factors, including memory, storage, I/O latency, concurrency, query design, indexing, PostgreSQL configuration, and application behaviour. Thus, this result should be viewed as a reference benchmark specific to the workload tested rather than a blanket performance claim. The most effective comparisons are made using a version of your workload that represents your needs.

Optimising your cloud setup is not just a one-off task. A server chosen years ago might still function well but could be missing out on newer and better price-performance improvements. Regular reviews of your infrastructure help teams spot opportunities for better choices before outdated options become a financial or capacity burden.

Teams should consistently assess:

• The compute family options available in their Azure regions
• Utilisation of CPU, memory, storage, and I/O
• Current and anticipated workload demands
• Transactions or queries achieved per cost unit
• Performance under typical load conditions
• Migration needs and expected downtime

For more tips on optimising Azure Database for PostgreSQL workloads, visit Plan Azure Database for PostgreSQL flexible server deployments for operational performance on Microsoft Learn.

Azure’s ongoing investments in regions, data centres, and computing infrastructure create new opportunities for enhancing your workloads. To benefit from this investment, it’s crucial to keep assessing newly available options, measuring them against actual application behaviour, and adopting improvements when there’s a compelling business case.

By combining Microsoft’s continuous platform investment with your proactive optimisations, you can forge a partnership aimed at enhancing your business’s performance, scalability, and success.

This appendix includes the resources and provisioning steps used for our benchmark.

The benchmark was set up using this bicep file definition, titled “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 for 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'
    }
  }
]

Additionally, this plpgsql function was created to prioritise 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;
$$;

1. Set up two Azure Database for PostgreSQL flexible servers using comparable V3 and V5 compute configurations with this CLI command:

   $password = Read-Host "Password" -MaskInput
   az deployment group create `
   --resource-group  `
   --template-file ./postgres-flex-compute-benchmarks.bicep `
   --parameters administratorLoginPassword="$password"

2. After provisioning the servers, establish the “leibniz_pi” function on each server.
3. Execute a pgbench using containerised environments, passing in the custom plpgsql function:

   'SELECT leibniz_pi(10000000);' |
   docker run --rm -i `
   -e PGPASSWORD="" `
   postgres:18 `
   pgbench -n -c 8 -j 8 -T 300 -f - `
   "host=.postgres.database.azure.com port=5432 dbname=postgres user=benchAdmin sslmode=require"

4. Repeat the test runs, documenting transaction throughput, execution time, and essential resource metrics.
5. Evaluate the results while considering workload variability and any distinctions in the compute architecture utilised.