PostgreSQL - consider enabling autogrow on non-production projects

Storage autogrow for Azure Database for PostgreSQL Flexible Server automatically increases a server's provisioned storage when free space runs low, instead of requiring a manually sized disk from day one. Enabling it on non-production servers lets teams start with a smaller disk and avoid paying for storage capacity that may never be used. This policy applies to non-production PostgreSQL Flexible Server instances, such as development, staging, and QA environments, where usage patterns are still uncertain.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Azure Database for PostgreSQL Flexible Server does not support decreasing storage after it's provisioned. The only way to reduce disk size is to dump and restore into a new server. That one-way constraint pushes teams toward guessing high on non-production servers, provisioning 128 GiB or more "just in case" for a workload that may only need 32 GiB.

Storage autogrow removes the need for that guess. When enabled, Azure Database for PostgreSQL Flexible Server automatically expands storage once free space drops below a threshold, rather than requiring the team to predict peak usage months in advance.

Over-provisioning non-production storage is a defensive habit, not a technical requirement. Autogrow lets teams start small and let real usage drive growth instead of a guess baked into the initial Terraform configuration.

Potential Savings

A non-production PostgreSQL Flexible Server started at the 32 GiB minimum instead of a defensively sized 128 GiB disk avoids paying for roughly three-quarters of the provisioned storage, until the workload actually needs more. Because Azure bills for provisioned storage rather than storage actually used, that gap persists for as long as the oversized disk exists.

Teams that enable autogrow on new non-production servers consistently start smaller. Teams that provision ahead of any usage data tend to carry that unused capacity for the life of the environment.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a non-production server provisioned defensively at a large fixed size, and the corrected configuration that starts small with autogrow enabled.

Non-compliant configuration: fixed storage sized for an unproven workload

resource "azurerm_postgresql_flexible_server" "dev" {
  name                   = "topco-dev-postgres"
  resource_group_name    = azurerm_resource_group.dev.name
  location               = azurerm_resource_group.dev.location
  version                = "16"
  administrator_login    = var.admin_login
  administrator_password = var.admin_password
  sku_name               = "B_Standard_B1ms"
  storage_mb             = 131072
  storage_tier           = "P10"
  zone                   = "1"
}

resource "azurerm_postgresql_flexible_server" "dev" {
  name                   = "topco-dev-postgres"
  resource_group_name    = azurerm_resource_group.dev.name
  location               = azurerm_resource_group.dev.location
  version                = "16"
  administrator_login    = var.admin_login
  administrator_password = var.admin_password
  sku_name               = "B_Standard_B1ms"
  storage_mb             = 131072
  storage_tier           = "P10"
  zone                   = "1"
}

resource "azurerm_postgresql_flexible_server" "dev" {
  name                   = "topco-dev-postgres"
  resource_group_name    = azurerm_resource_group.dev.name
  location               = azurerm_resource_group.dev.location
  version                = "16"
  administrator_login    = var.admin_login
  administrator_password = var.admin_password
  sku_name               = "B_Standard_B1ms"
  storage_mb             = 131072
  storage_tier           = "P10"
  zone                   = "1"
}

This provisions 128 GiB (storage_mb = 131072) on a development server before any usage data exists to justify it. Because storage can't be scaled back down, this size is now a fixed cost for the life of the server. This is a common source of wasted spend on non-production databases.

Compliant configuration: minimum storage with autogrow enabled

resource "azurerm_postgresql_flexible_server" "dev" {
  name                   = "topco-dev-postgres"
  resource_group_name    = azurerm_resource_group.dev.name
  location               = azurerm_resource_group.dev.location
  version                = "16"
  administrator_login    = var.admin_login
  administrator_password = var.admin_password
  sku_name               = "B_Standard_B1ms"
  storage_mb             = 32768
  storage_tier           = "P4"
  auto_grow_enabled      = true
  zone                   = "1"
}

resource "azurerm_postgresql_flexible_server" "dev" {
  name                   = "topco-dev-postgres"
  resource_group_name    = azurerm_resource_group.dev.name
  location               = azurerm_resource_group.dev.location
  version                = "16"
  administrator_login    = var.admin_login
  administrator_password = var.admin_password
  sku_name               = "B_Standard_B1ms"
  storage_mb             = 32768
  storage_tier           = "P4"
  auto_grow_enabled      = true
  zone                   = "1"
}

resource "azurerm_postgresql_flexible_server" "dev" {
  name                   = "topco-dev-postgres"
  resource_group_name    = azurerm_resource_group.dev.name
  location               = azurerm_resource_group.dev.location
  version                = "16"
  administrator_login    = var.admin_login
  administrator_password = var.admin_password
  sku_name               = "B_Standard_B1ms"
  storage_mb             = 32768
  storage_tier           = "P4"
  auto_grow_enabled      = true
  zone                   = "1"
}

This starts at the 32 GiB minimum and sets auto_grow_enabled = true, so Azure Database for PostgreSQL Flexible Server expands storage automatically if the server approaches its capacity limit. The team pays for 32 GiB until real usage justifies more, rather than for a peak that may never arrive.

Step-by-Step Fix Instructions

1. List every azurerm_postgresql_flexible_server resource in Terraform state tagged as non-production, and note each one's current storage_mb and auto_grow_enabled value.

2. For any server missing auto_grow_enabled or set to false, add auto_grow_enabled = true to the resource configuration.

3. Confirm the server's storage_tier uses standard Premium SSD rather than Premium SSD v2. Storage autogrow is not supported on Premium SSD v2.

4. Where a non-production server was already provisioned with defensively large storage, treat the current size as a fixed cost going forward. Reducing it requires a manual dump and restore to a new, smaller server.

5. Run terraform plan and confirm the change only adds auto_grow_enabled, then apply it.

6. Add Infracost to CI/CD so any future azurerm_postgresql_flexible_server resource added to a pull request without auto_grow_enabled gets flagged for review before merge.

Best Practices

• Default new non-production PostgreSQL Flexible Server modules to auto_grow_enabled = true paired with the smallest viable starting storage_mb, rather than a size chosen defensively.

• Reserve manually sized, non-autogrow storage decisions for production servers, where predictable capacity planning usually matters more than convenience.

• Pair autogrow with storage utilization alerts. Autogrow is not instantaneous, and it doesn't protect against a sudden, extreme spike in disk usage.

• This policy does not apply to production PostgreSQL Flexible Server instances by default. Production capacity planning deserves a deliberate sizing decision instead of autogrow left to its own defaults.

Tools and Scripts

Infracost supports this policy check in its free trial and paid plans. When Infracost runs in CI/CD, it evaluates azurerm_postgresql_flexible_server resources introduced or modified in a pull request and flags non-production servers where auto_grow_enabled is missing or set to false, surfacing the finding as a warning in the PR comment before the change merges.

This gives platform teams a pre-deployment signal instead of discovering an oversized, fixed-cost disk on next month's bill. Infracost enables teams to track how many non-production servers are missing autogrow over time, which supports burning down this category of waste incrementally and reporting progress to engineering leadership.

To check a server's current storage configuration using the Azure CLI:

az postgres flexible-server show --resource-group <resource-group> --name <server-name> --query "storage"

az postgres flexible-server show --resource-group <resource-group> --name <server-name> --query "storage"

az postgres flexible-server show --resource-group <resource-group> --name <server-name> --query "storage"

Examples of Impact

Illustrative example: provisioning ahead of any usage data. A platform team provisions a 128 GiB non-production PostgreSQL Flexible Server for a staging environment "to be safe," and the workload never grows past 20 GiB over the following year. Starting at the 32 GiB minimum with autogrow enabled would have avoided paying for the unused difference for the life of the environment.

Illustrative example: an unexpected growth event. A QA team runs a larger-than-usual load test against a non-production server without autogrow enabled, and the server hits its storage limit and becomes read-only mid-test. Enabling auto_grow_enabled in advance would have let storage expand automatically, keeping the test running while flagging the growth for later review.

(These are illustrative, composite scenarios, not specific customer accounts.)

Considerations and Caveats

• Storage only scales up: Azure Database for PostgreSQL Flexible Server does not support decreasing storage size after it's provisioned. Reducing it requires a manual dump and restore to a new server.

• Premium SSD only: Storage autogrow is only supported on standard Premium SSD storage, not Premium SSD v2.

• Growth doubles the disk: When autogrow triggers, storage typically doubles in size, which also doubles the associated storage cost. This is a cost event worth monitoring, not a one-time convenience.

• Scoped to non-production: This policy targets non-production servers specifically. Production capacity planning generally benefits from a deliberate sizing decision rather than relying on autogrow's doubling behavior at scale.

• Provider-specific: This policy is specific to Azure Database for PostgreSQL Flexible Server and the azurermTerraform provider. Other managed PostgreSQL services have their own storage-scaling mechanisms, but the resource and attribute names differ.

Related Policies and Concepts

• PostgreSQL - consider using backup retention in non-production projects: another Compute-group FinOps policy focused on right-sizing non-production PostgreSQL configuration rather than paying for production-level defaults by habit.

• RDS - consider upgrading gp2 storage type to gp3: a related Compute-group policy that reduces managed database storage cost through a configuration change, the same underlying discipline this policy applies to non-production storage sizing.

• "How to Enforce Cloud Cost Policies in Your CI/CD Pipeline": a planned Infracost resource article covering the broader workflow of catching cost policy violations like this one at the pull request stage, before they reach production billing.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. Infracost evaluates azurerm_postgresql_flexible_server resources in pull requests and flags non-production servers where auto_grow_enabled is missing or set to false, so the team can confirm the configuration before merge. This check is available in the free trial and all paid plans.

Can this policy be customized?

Yes. Teams can adjust the policy's scope in Infracost, for example limiting the check to specific resource groups or naming patterns used to identify non-production PostgreSQL Flexible Server instances, rather than relying on the default configuration.

Does Infracost automatically fix violations?

No. Infracost identifies and reports an azurerm_postgresql_flexible_server resource in a pull request that doesn't have auto_grow_enabled set to true. Adding the attribute and applying the change is a decision the team makes and carries out manually.

Is this policy cloud-agnostic?

No. This specific policy targets Azure Database for PostgreSQL Flexible Server and its Terraform provider, azurerm. Other clouds and other managed PostgreSQL services have their own storage-scaling mechanisms, but the Terraform resource names and attributes differ.

How often should I review storage autogrow settings?

Teams running Infracost in CI/CD get a check on every pull request that touches an azurerm_postgresql_flexible_serverresource. For servers already running, reviewing storage utilization and auto_grow_enabled settings on a recurring basis, monthly is a reasonable cadence for most non-production environments.

Does enabling storage autogrow affect PostgreSQL Flexible Server performance?

It can, in a specific way. Storage autogrow on Azure Database for PostgreSQL Flexible Server only supports Premium SSD storage, and when it triggers, storage typically doubles in size, which also doubles the associated storage cost. This policy recommends monitoring storage growth events rather than assuming autogrow is cost-neutral.

What is the minimum storage size for Azure Database for PostgreSQL Flexible Server?

The minimum storage size for Azure Database for PostgreSQL Flexible Server is 32,768 MB, or 32 GiB. Storage can only be scaled up from that point, decreasing it after provisioning isn't supported.