What changed

Microsoft announced Extended Support for Azure Database for PostgreSQL Flexible Server on 24 August 2026, describing it as a way to maintain secure, supported workloads while transitioning to newer versions and to upgrade on your own timeline with greater flexibility and confidence. The mechanism behind that description is where the decision lives. Microsoft’s version policy places the Azure Standard Support End Date for PostgreSQL 11, 12 and 13 at 31 July 2026, a date that has already passed. The Extended Support documentation then states that on 1 August 2026 the service automatically enrolls PostgreSQL servers running unsupported versions in Extended Support, that a one-month grace period is provided for versions 11, 12 and 13, and that extended support billing starts on 1 September 2026. Enrolment is not an offer that was accepted. It is a state that servers were placed into, and the grace period is the only reason it has not yet appeared on an invoice. Extended Support runs to 31 March 2027 for version 11, 13 November 2027 for version 12 and 12 November 2028 for version 13. Version 14 follows later in the year, on a date the two Microsoft pages state differently, which is why no day is quoted here.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

Azure Database for PostgreSQL Flexible Server is Microsoft’s managed PostgreSQL service. A major version is a change in the first number, so PostgreSQL 13 to 14 is a major version upgrade; those are the versions the PostgreSQL community supports on a fixed schedule and eventually retires. Azure Standard Support is the period during which Azure applies engine security patches and Microsoft can support engine issues. Extended Support is a new, chargeable tier that continues security patches and critical bug fixes after standard support ends, for up to three additional years, so that a customer can plan an upgrade rather than be forced into one.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

PostgreSQL 11, 12 and 13 left Azure standard support on 31 July 2026. On 1 August Azure automatically enrolled every Flexible Server still running those versions into Extended Support, and the one-month grace period ends on 1 September 2026, when billing starts. Microsoft’s own FAQ states there is no opt-out: the only way to stop the charge is to upgrade.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

The first thing to establish is that opting out is not one of the options. Microsoft’s FAQ asks directly whether a customer can keep running without extended support and opt out, and answers No, adding that extended support is automatically applied to eligible servers and that to stop the charges the server must be upgraded to a supported PostgreSQL version. The real decision is therefore per server, and there are three defensible answers. Upgrade before 1 September and avoid the charge entirely. Accept the charge deliberately, for a server whose application cannot safely be upgraded inside a week, and treat Extended Support as what Microsoft itself calls it, a temporary bridge rather than a long-term solution. Or stop a server that is not actually needed, because Microsoft states that billing applies only to servers in a Succeeded, running state and that a stopped, deleted or failed server is not charged for that period. Two further facts shape the sums. Microsoft bills for the time a server runs on an unsupported version, so an upgrade completed part-way through September is charged only for the days before it completed rather than the whole month. And where regional capacity constraints prevent an upgrade, Microsoft states a server might be temporarily excluded from extended support billing until capacity becomes available, with support channels validating eligibility. What Extended Support buys is narrower than ordinary support: security patches, critical bug fixes and technical assistance through existing support channels, explicitly excluding new features, performance enhancements, general bug fixes, performance tuning assistance and support for minor version upgrades. Braintree’s view, not Microsoft’s, is that the cost of this is secondary to what it reveals. A database on a version the community retired in 2023 or 2024 has been carrying an unpatched engine risk that nobody priced, and the invoice arriving in September is simply the first time that risk has had a number attached to it.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Start with the inventory, because it bounds everything else and takes minutes. List every Flexible Server across every subscription with its major version; the Azure portal and the Azure CLI both indicate whether a server is enrolled in Extended Support, and Microsoft states the portal also surfaces indicators for servers approaching end of support. For each server on 11, 12 or 13, establish the upgrade target before scheduling anything: Azure supports in-place major version upgrades only to versions that are currently supported at the time of the upgrade, and Microsoft warns that attempting to upgrade to a deprecated version may result in failure or service disruption. Then test, because a major version upgrade is an application change as much as a database one. Microsoft’s own caution is that upgrades can introduce deprecated configuration parameters, incompatible extensions and SQL behaviour differences, and that application compatibility and extension support should be validated in a non-production environment before a production upgrade is scheduled. The trap most likely to be missed is extensions. Microsoft states plainly that while Azure upgrades the database engine, non-core extensions require manual updates, naming pgvector and timescaledb as examples, and that the fix is to run ALTER EXTENSION … UPDATE or to recreate unsupported extensions after the upgrade. An upgrade that leaves an extension on its old version is not a completed upgrade. To reduce downtime, Microsoft recommends planning for low-traffic hours, identifying upgrade blockers such as extensions, roles and replication slots in advance, pausing background jobs and long-running sessions, temporarily scaling up compute to speed up pg_upgrade, clearing bloat with VACUUM or REINDEX where needed, and running ANALYZE afterwards to restore performance. Parameter defaults are handled by the upgrade workflow in most cases, but application-specific settings should be reviewed afterwards.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The budget holder for Azure, with the data platform or database lead.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: List every Azure Database for PostgreSQL Flexible Server and the major version each one runs. Anything on 11, 12 or 13 is already enrolled and starts billing on 1 September. Decide per server whether to upgrade before that date, accept the charge as a deliberate cost, or stop a server that is not needed.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The dated inventory of Flexible Servers with their major versions and subscriptions, the portal or CLI indicator showing which are enrolled in Extended Support, the per-server decision with its date, and for anything upgraded, the extension update record and a post-upgrade application test result.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

Were we asked to join this?

No. Microsoft states that on 1 August 2026 the service automatically enrolls PostgreSQL servers running unsupported versions in Extended Support.

Can we opt out?

Microsoft’s FAQ answers this directly: No. Extended support is automatically applied to eligible servers running unsupported versions, and the only way to stop the charges is to upgrade to a supported version.

When does it start costing money?

1 September 2026. Microsoft provides a one-month grace period for versions 11, 12 and 13, and states that extended support billing starts on that date.

Which versions are affected?

PostgreSQL 11, 12 and 13 left Azure standard support on 31 July 2026 and were enrolled on 1 August. Version 14 follows later in the year; Microsoft’s version policy page and its extended support page give different dates for that one, so confirm it directly before planning against a specific day.

What if we upgrade halfway through the month?

Microsoft states that charges are based on the time a server runs on an unsupported version, so an upgrade completed during a billing period is charged only for the time before the upgrade completed.

What if the server is switched off?

Microsoft states that billing applies only to servers in a Succeeded, running state, and that a stopped, deleted or failed server is not charged for that period. Billing resumes when it returns to a running state on an end-of-life version.

What do we actually get for the money?

Security patches, critical bug fixes and technical assistance through your existing support plan, for up to three additional years. Microsoft explicitly excludes new features, performance enhancements, general bug fixes, performance tuning assistance and support for minor version upgrades.

Will our extensions be upgraded with the engine?

No. Microsoft states that non-core extensions such as pgvector and timescaledb require manual updates after the upgrade, using ALTER EXTENSION … UPDATE or by recreating them.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.