Upgrade Cadence Control
also called Version Schedule Ownership, Forced Upgrade Window
Who gets to choose when a dependency's major version changes - the hidden half of the managed-versus-self-managed trade, and the reason a managed service can create work you did not schedule.
A team moves its database to a managed service and the operational argument is settled: backups, failover and patching are someone else's job. Fourteen months later an email gives a date when the major version it runs stops being supported, with an automatic upgrade in a maintenance window if the team does not act first. The work is now on the roadmap, unplanned, and the application has never been tested against the new version.
Nothing went wrong. The team traded operational toil for schedule control and only priced the first half. Managed services remove the mechanics of an upgrade; they do not remove the deadline, the compatibility testing, or the fact that the deadline belongs to someone else.
Why it matters
Version deadlines are the most predictable unplanned work in infrastructure. They land in whichever quarter the provider chose, cannot be deferred past end of support by negotiation, and the cost is not the upgrade - it is the regression testing of every application that talks to the thing.
The default should still be managed. One of the few arguments for deviating is a hard version pin - an extension the provider does not offer, a certification forbidding an unplanned change - and those are schedule-control arguments, the only form of "we must run it ourselves" that survives scrutiny at small scale.
Implementation patterns
- Record the end-of-support date on the day you provision, beside the renewal date.
- Rehearse the upgrade on a restored copy at least one quarter out. A restore plus an upgrade plus the application's test suite is 4 to 8 hours of work that converts an unknown into a plan, and it is the single highest-value hour in the whole exercise.
- For self-managed, publish your own cadence and negotiate extended support as a price where it is sold. A team with no stated cadence does not have schedule control; it has drift, and ends up several versions behind a security fix it cannot take.
Industry example
PostgreSQL's versioning policy is the clean case, because the upstream schedule is published and every provider inherits it. The project supports each major version for five years from its initial release and ships a major version roughly annually; version 14's final release is dated 12 November 2026. The policy is explicit that major versions cannot be upgraded in place - either a dump and reload, or pg_upgrade.
That is the mechanism behind every managed-service upgrade email: the provider cannot make an in-place major upgrade exist, only automate the cut-over and pick the window.
Failure scenarios
- The forced upgrade during the busiest month, because the deadline landed in Q4 and nobody looked at the date in Q1.
- An extension or data type the new version drops, found during the upgrade rather than a rehearsal, so the cut-over rolls back and the deadline stays.
- A self-managed cluster three major versions behind, where the next security advisory requires a multi-step upgrade nobody has practised.
- Silent behavioural change - a planner change making one query ten times slower - caught in production because the rehearsal ran the test suite but not the production query mix.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Managed | Backups and failover operated, upgrade mechanics automated | The provider's end-of-support dates and maintenance windows |
| Self-managed | You pick the quarter and can defer for a certification | Patching, backup verification, failover tooling, and the drift risk if you never choose |
The asymmetry: managed removes work that is easy to do badly and adds a deadline that is easy to plan for. Self-managing removes the deadline and adds work that compounds quietly.
When not to use it
Do not let schedule control drive the decision at small scale. Below roughly 500 dollars a month of managed spend, the saving from self-managing is smaller than the cost of one restore drill, and "we want to control our upgrade window" is a rationalisation. The argument earns its place only when a specific pin can be named: this extension, this certification, this certified vendor application.
Nor does a database abstraction layer make a version reversible: compatibility breaks at the semantics - planner behaviour, data types, extensions - not at the call interface.
Interview question
Q: Your team self-manages a datastore partly because an auditor requires the version frozen between certifications. The managed alternative would save about half an engineer's time. How do you decide, and what goes in the decision record?
What a strong answer covers: separating the two things being bought - operational toil and schedule control; checking whether the provider sells extended support or version pinning, which would collapse the trade; the five-year upstream clock, and that freezing is deferral rather than avoidance; the trigger that would reopen the choice; and the rehearsal either way, because the cut-over mechanics are identical.
Quick check
Quiz: A provider announces your major version's end of support in nine months. What do you schedule first? A rehearsal: restore a copy, upgrade it, run the test suite and the production query mix - half a day that turns the deadline into a plan.
Flashcard: What does a managed service not remove about upgrades? - The deadline and the compatibility testing. It automates the cut-over; the five-year support clock and your regression risk stay yours.