The PostgreSQL API Version in Your Bicep Is Already a Year Behind

The ticket said “turn on WORM backups for the compliance team by Friday.” The compliance team had read a slide. The slide said Azure Database for PostgreSQL Flexible Server, that’s the fully managed Postgres service, the one where Microsoft patches the OS and you pretend you don’t miss running your own, now does immutable backup retention. True enough. What the slide didn’t say is that the feature rides on a brand-new REST API version, 2026-10-01, announced GA on November 7, and that the Bicep module running that server was pinned to a 2025 version written by someone who left the company.

So before I turned anything on, I had to find out what I was actually running.

First instinct is wrong. az resource show gives you the current state of the resource, not the API version your IaC used to deploy it, ARM doesn’t stamp that on the object. The honest way to find your pin is to grep your templates and read the deployment history.

1
2
3
4
5
6
7
8
9
10

# what API versions does the RP even offer right now?
az provider show --namespace Microsoft.DBforPostgreSQL \
  --query "resourceTypes[?resourceType=='flexibleServers'].apiVersions | [0]" -o tsv
​
# what did my last deployment actually use?
az deployment group show -g rg-data-prod -n pg-flex-deploy \
  --query "properties.outputResources[].id" -o tsv
​
# and the blunt one: find every pinned version in the repo
grep -rn "Microsoft.DBforPostgreSQL/flexibleServers@" ./infra

That last line found four modules on three different API versions. Nobody plans for that. It just happens, one hotfix at a time.

What 2026-10-01 actually adds

The announcement names three areas: maintenance management, immutable backups, and multi-tenant encryption. Read it closely and it’s a headline, not a spec sheet, so take what follows as the shape of the thing, confirmed against the API reference before you ship.

Maintenance management “got richer” is about as specific as the update text gets. I’d love to tell you it adds scheduled custom windows and the ability to defer non-critical updates, because that’s what the slide-makers imply, but the announcement doesn’t spell either out. Don’t quote me, or them, on exact knobs until the REST reference for 2026-10-01 lists the properties.

Immutable backups are the clearer win: WORM-style retention locks, so a retention policy can’t be shortened or deleted even by an owner. That’s the entire point for anyone living under a regulator. And cross-tenant customer-managed keys let the encryption key live in a Key Vault in a different tenant from the server. If you’re an MSP or running multi-tenant SaaS and your customer insists on holding their own key material, this is the feature that stops you running a separate deployment per customer.

Now the question everyone actually has: will bumping the pin break the server already running? ARM API updates are typically additive, new fields, old behaviour unchanged, and that’s the direction I’d bet on here. But the update text doesn’t promise it, and I’m not going to promise it for Microsoft. Read the migration guidance for this resource type before you assume a version bump on a module that doesn’t touch the new fields is a no-op. In my case it was. Yours might differ, and 2 a.m. is a bad time to learn the word “regression.”

Here’s the honest version of the change I made. The diff that matters is one line, the API version on the resource, plus whatever property the GA reference tells you drives immutable retention. I’m deliberately not inventing that property name.

1
2
3
4
5
6
7
8
9
10
11
12
13

resource pg 'Microsoft.DBforPostgreSQL/flexibleServers@2026-10-01' = {
  name: serverName
  location: location
  properties: {
    version: '16'
    backup: {
      backupRetentionDays: 35
      // the immutable-retention property is new in 2026-10-01.
      // look up its exact name + allowed values in the GA REST
      // reference for flexibleServers before you add it here.
    }
  }
}

1
2

az deployment group create -g rg-data-prod \
  --template-file ./infra/pg.bicep --parameters @prod.json --what-if

I ran it with --what-if first, because changing a backup policy in anger is how you discover your own humility. The spelling of the new field is Microsoft’s to publish; confirm it against the reference for your exact SKU before you merge.

Terraform people, read this twice. The azurerm provider will not expose 2026-10-01 features the day they ship, it never does. If you need immutable backups now, you reach for the azapi provider and target the version directly, or you wait a release or two. Don’t open a GitHub issue demanding it by Friday. It won’t help and they’ve heard it.

Here’s what I actually did. I bumped the one module that needed WORM retention, confirmed the property name against the reference, tested it, shipped it. The other three modules I left exactly where they were. A new stable API version is permission to adopt features, not a mandate to retrofit your entire estate. Bump when a feature earns the diff. Otherwise the best API version is the boring one you already tested.