RDS Extended Support is een tussenfase
AWS heeft nieuwe Extended Support-minorversies uitgebracht voor RDS PostgreSQL 11, 12 en 13. Daarmee blijven kritieke fixes beschikbaar na community- en standaardsupport, maar de noodzaak van een geplande major upgrade verdwijnt niet.
- Auteur
- Intercube
- Gepubliceerd
- Leestijd
- 8 min leestijd
01
Wat AWS heeft uitgebracht
AWS kondigde op 29 september 2026 de Extended Support-minorversies 13.23-rds.20260514, 12.22-rds.20260514 en 11.22-rds.20260514 aan voor Amazon RDS for PostgreSQL. Extended Support kan tot drie jaar na het einde van standaardsupport kritieke kwetsbaarheids- en bugfixes leveren.
De release is relevant omdat PostgreSQL 11, 12 en 13 geen normale doelen meer zijn voor nieuw platformwerk. AWS kan geselecteerde engine-branches na het einde van de community-lifecycle onderhouden, maar de database blijft op een oude majorversie met een eindige AWS-supportdatum en aanvullende Extended Support-kosten.
Installeer de relevante Extended Support-update via het normale wijzigingsproces. Test extensies, applicatieverbindingen, replica's en prestaties voor productie. De update lost problemen op die in die AWS-build zijn opgenomen, maar maakt de majorversie niet actueel en bewijst niet dat iedere applicatiedependency klaar is voor de uiteindelijke upgrade.
02
Gebruik de extra tijd doelgericht
Extended Support is nuttig wanneer een majorversiewijziging meer voorbereiding vraagt dan het standaardvenster biedt. Geselecteerde kritieke fixes blijven beschikbaar terwijl teams extensiecompatibiliteit, applicatieaannames en releaseafhankelijkheden oplossen. Dat is een beheerste overbrugging, geen reden om de upgrade zonder eigenaar te laten.
Kies een doelversie en definitieve migratiedatum voordat de eerste Extended Support-wijziging plaatsvindt. Plan vervolgens terug via applicatietests, extensie-upgrades, parameterwijzigingen, replicatiekeuzes en het onderhoudsvenster. Zonder die data kan een betaalde overgangsperiode ongemerkt het vaste beheermodel worden tot AWS de laatste deadline bereikt.
Kosten horen in die beslissing. Vergelijk de Extended Support-kosten en het terugkerende beheerwerk met de engineering die voor een upgrade nodig is. Een korte overbrugging kan deliverycapaciteit beschermen. Meerjarig uitstel kan hetzelfde budget besteden zonder de applicatie, databasearchitectuur of supportpositie te verbeteren.
- Bevestig iedere RDS-cluster, instance, replica en majorversie binnen scope.
- Inventariseer extensies en applicatielibraries die de doelversie beperken.
- Kies een doelrelease en omschakeldatum terwijl de overbrugging nog optioneel is.
- Volg Extended Support-kosten afzonderlijk van normale databasecapaciteit.
03
Kies de upgraderoute op basis van risico
AWS noemt Blue/Green Deployments, in-place major upgrades en herstel vanuit een snapshot als beschikbare routes. De juiste keuze hangt af van databaseomvang, toegestane onderbreking, schrijfgedrag, extensiecompatibiliteit en het rollbackmodel. Een bekende knop is nog geen upgradestrategie.
Blue/Green Deployments maken een parallelle stagingomgeving en een beheerste omschakeling mogelijk, maar AWS documenteert beperkingen die voor de exacte engine en topologie moeten worden gecontroleerd. Een in-place upgrade wijzigt de bestaande database en kan passen wanneer onderhoudsvenster en rollbackvoorbereiding voldoende zijn. Snapshotherstel biedt een andere geïsoleerde route, waarbij het plan rekening moet houden met datawijzigingen na de snapshot.
Repeteer met een recente, productieachtige kopie, meet de duur van iedere fase en test queries die voor de applicatie belangrijk zijn. Vergelijk parametergroepen, extensieversies, collationgedrag, replicatie, connection pools en monitoring. Het omschakelplan benoemt wie kan stoppen, welk signaal rollback activeert en hoe writes consistent blijven.
04
Geef de database een lifecycle-eigenaar
AWS beheert de RDS-dienst, maar het applicatieteam blijft eigenaar van majorversiekeuzes, schemagedrag, extensies, parameters en het moment van wijziging. Managed infrastructuur hoort die verantwoordelijkheid expliciet te maken en leveranciersdeadlines zichtbaar te houden voordat zij spoedwerk veroorzaken.
Intercube managed AWS verbindt deze planning met de rest van de applicatieomgeving. Wij kunnen databasedependencies inventariseren, het doel kiezen en testen, de omliggende infrastructuur als code vastleggen, de omschakeling begeleiden en het platform daarna blijven beheren. Het resultaat is niet alleen een nieuwere engine, maar een herhaalbare route voor de volgende lifecyclewijziging.
Als het huidige AWS-ontwerp meer complexiteit draagt dan de applicatie nodig heeft, kan dezelfde analyse een beheerd Intercube-hostingdoel vergelijken. De beslissing moet applicatie-eisen behouden en vermijdbaar platformwerk verminderen, niet alleen de naam van de leverancier veranderen.
Prioriteiten voor RDS PostgreSQL
- Installeer de toepasselijke Extended Support-minorversie via een getest wijzigingsproces.
- Behandel Extended Support als een gedateerde overbrugging naar een nieuwere PostgreSQL-majorversie.
- Inventariseer extensies, parameters, replica's en applicatielibraries voordat je de route kiest.
- Repeteer upgradeduur, applicatiegedrag, omschakeling en rollback met representatieve data.
- Wijs doorlopend eigenaarschap toe voor de lifecycle van databases en AWS-diensten.