AWS giveth with its right hand and breaketh with its left
Summary
AWS ended standard support for PostgreSQL 13 on Amazon RDS, urging customers to upgrade to PostgreSQL 14 or later. PostgreSQL 14 defaults to the more secure SCRAM-SHA-256 authentication, but AWS Glue’s connection-testing tooling uses an older driver that cannot handle that authentication method. As a result, upgrading RDS to the recommended, more secure version can break Glue-based ETL pipelines: the “Test Connection” function fails and, in many reports, crawlers fail too.
The incompatibility has been known since PostgreSQL 14 shipped in 2021, but the gap between RDS and Glue remained unaddressed. AWS offers three customer workarounds—downgrade authentication, supply your own JDBC driver (which disables connection testing), or rewrite ETL jobs as Python shell tasks—all of which undermine the value of the managed services or the security improvement. Customers who stayed on PG13 to avoid the issue may now be moved onto AWS Extended Support (paid) unless they opted out at cluster creation time, a potentially expensive outcome.
Key Points
- AWS ended standard support for PostgreSQL 13 on RDS; upgrades to PG14+ are encouraged.
- PostgreSQL 14 defaults to SCRAM-SHA-256 authentication, which AWS Glue’s connection tester doesn’t support due to an outdated internal driver.
- Upgrading RDS as recommended can break Glue ETL pipelines; the issue was known since 2021 but persisted across service teams.
- AWS-provided fixes are unsatisfactory: weaken DB auth, use a custom JDBC driver (losing tests), or rework ETL to non-managed approaches.
- Extended Support may be applied automatically and can be expensive (example: roughly $0.10/vCPU-hour, adding up quickly for large instances).
- The root cause is organisational silos and service-team boundaries, not malice—yet customers bear the operational and financial cost.
Why should I read this?
Short version: if you run RDS Postgres with AWS Glue, this could break your pipelines overnight. Read it so you don’t wake up to failed ETL jobs and a surprise bill. Seriously — check what Postgres version your clusters use and whether Extended Support has been enabled.
Context and relevance
Punchy take: this is a classic cloud-scale coordination failure. It shows how independent roadmaps across semi-autonomous teams in a huge vendor can produce real, costly problems for customers. For engineers and ops teams the article is highly relevant — it flags an immediate operational risk and forces choices between security, functionality and cost. For decision-makers it underlines the hidden fragility and potential vendor-billing implications of managed services.
This pattern isn’t unique to AWS; other major cloud providers face similar cross-service gaps. The practical takeaway is to verify inter-service compatibility before upgrading, monitor for automatic extended-support enrolment, and demand clearer cross-team ownerhip and pre-deprecation compatibility assurances from providers.
Article meta
Article Date: 2026-03-17T19:15:08+00:00
Article URL: https://go.theregister.com/feed/www.theregister.com/2026/03/17/aws_ends_support_postgresql_13_rds/
Article Image: vulture icon
