Why does a managed database service apply minor patches for you but wait for you to start a major version upgrade?

## Two changes that are not the same size Managed engines version in lines. A **minor** change moves within one major line and is a bug fix, a security fix or a small hardening; the contract it offers is that behaviour you already depend on keeps working. A **major** change opens a new line, and a new line is exactly where maintainers are allowed to remove things, change defaults and alter internals. The lifecycle a managed service wraps around them differs because the risk differs, not because one is bigger work for the provider. | | Minor patch | Major version upgrade | |---|---|---| | Who triggers it | The provider, in the maintenance window | You, at a time you choose | | Compatibility risk | Low, behaviour-preserving by intent | Real: defaults, syntax, planning, client libraries | | Who tests it | The provider validates the engine build | You validate your own workload | | Rollback | Restart on the previous build if needed | No in-place downgrade - restore or cut back to a copy | | Deadline | None you manage | An end-of-support date that eventually forces it | ## Why the provider takes the minor one Three reasons stack up. 1. **It can be validated once.** The provider runs the same engine build for every customer on that line, so one validation pass covers the fleet. 2. **There is an obligation behind it.** A managed service exists because the provider operates the software; leaving known-vulnerable builds running is exactly what customers bought their way out of. 3. **The blast radius is a restart.** The worst realistic outcome is the interruption you already accepted when you nominated a window. This is why a fleet on a managed tier is, in practice, patched more consistently than a fleet of self-run instances: nobody has to remember. ## Why the major one waits for you A major upgrade can change things no provider can check on your behalf: - **Removed or renamed syntax** a query, view or stored routine still uses. - **Changed defaults** - a setting whose old value your workload silently relied on. - **A changed planner default**, so a query that was fast becomes slow on the same data, which is a load problem rather than an error. - **Client library and driver requirements**, where the application side needs an upgrade before it can talk to the new engine at all. - **Extensions or add-on components** that have their own compatibility matrix and may lag the engine. None of that shows up in a generic validation pass. It shows up when your workload runs. So the platform hands you the trigger, and with it the testing and the scheduling. ## What owning it actually means 1. **Inventory** every instance on the old major line, including the forgotten ones in non-production accounts. 2. **Rehearse** on a restored copy: run the upgrade against a real copy of the data and time it. 3. **Test the clients**, not just the engine - the driver version is as likely to block you as the queries. 4. **Choose the cutover shape.** Designs differ here: some platforms upgrade in place with an outage you must budget for, and others let you build a parallel copy, replicate into it and switch the endpoint, which trades a shorter outage for more moving parts. 5. **Keep a way back.** Take a restore point immediately before the cutover, or keep the old copy readable until you are confident, because there is no in-place downgrade. ## The part people miss Customer-initiated is not the same as optional. The same lifecycle that lets you choose the moment also puts a date on the old line. Once the end-of-support date passes, the choice returns to the provider, which applies the upgrade on its own schedule - typically inside your maintenance window, and without your rehearsal. The value of owning the trigger is entirely in using it before that date, and a team that defers a major upgrade for two years has not avoided the work; it has only arranged for the work to happen on someone else's calendar.