AWS's PostgreSQL 13 End-of-Life Creates Catch-22 for Customers

AWS's recent decision to end standard support for PostgreSQL 13 on RDS has created an unexpected Catch-22 for customers, forcing them to choose between following AWS's own security recommendations and maintaining functional data pipelines. The situation highlights the challenges of managing complex cloud ecosystems where different AWS services operate with varying levels of coordination.

The Security Upgrade That Breaks Everything

The core of the problem lies in PostgreSQL 14's default authentication scheme. When PostgreSQL 14 shipped in 2021, it introduced SCRAM-SHA-256 as the default password authentication method, replacing the older MD5 scheme. This change represents a significant security improvement, as SCRAM-SHA-256 provides stronger protection against various attack vectors.

However, AWS Glue, the company's managed ETL (extract-transform-load) service, cannot handle this newer authentication scheme. When customers upgrade their RDS databases to PostgreSQL 14 or later to follow AWS's security guidance, Glue responds with "Authentication type 10 is not supported" and stops working entirely.

This creates a fundamental contradiction: AWS is actively encouraging customers to upgrade for security reasons while simultaneously breaking a core data processing service that many organizations rely on.

A Known Problem With No Clear Solution

What makes this situation particularly frustrating is that the incompatibility has been known since PostgreSQL 14's release in 2021. The deprecation timeline for PostgreSQL 13 was announced well in advance, giving AWS ample time to address the issue. Yet the problem persists, with community experts on AWS's support forum acknowledging three years ago that "the tester is pending a driver upgrade."

Even more concerning, users reported that crawlers—the primary mechanism for Glue to interact with databases—also fail when using the newer PostgreSQL versions. This isn't an edge case; running Glue against RDS PostgreSQL represents a bread-and-butter data engineering pattern that AWS has allowed to fall into disrepair.

The Three Bad Options

Faced with this incompatibility, AWS has provided customers with three solutions, each of which undermines the value proposition of using managed services:

1. Downgrade password encryption - Return to the older, less secure MD5 authentication scheme that PostgreSQL 13 used. This directly contradicts AWS's own security recommendations and exposes customers to known vulnerabilities.

2. Bring your own JDBC driver - This disables connection testing and may not support all desired features, essentially requiring customers to manage their own database connectivity within a managed service.

3. Rewrite ETL workflows - Convert Glue jobs to Python shell jobs, abandoning the managed ETL service entirely for a more manual approach.

The Extended Support Tax

For customers who stayed on PostgreSQL 13 to avoid this specific problem, AWS's Extended Support has been running automatically unless they opted out at cluster creation time. This detail is easy to miss and results in charges of $0.10 per vCPU-hour for the first two years, doubling in year three.

For a 16-vCPU Multi-AZ instance, this works out to nearly $30,000 per year in Extended Support fees alone. While AWS doesn't need to be running a shakedown, the result is indistinguishable from one: a number that appears on a bill from a company that controls both the timeline for fixing the problem and all customer response options.

Organizational Complexity as the Root Cause

The charitable interpretation of this situation is also the correct one: AWS has tens of thousands of engineers organized into hundreds of semi-autonomous service teams. The RDS team manages deprecations on the RDS lifecycle, the Glue team maintains driver dependencies on the Glue roadmap, and nobody explicitly owns the gap between them.

This isn't a conspiracy or a carefully-constructed revenue-enhancement mechanism. AWS lacks the internal cohesion needed to pull off such schemes. Instead, it's simply organizational complexity doing what organizational complexity does. It's the same reason internal tools at any large company don't talk to each other; AWS is just doing it at a scale where the blast radius is someone else's production database.

Integration Testing Across Service Boundaries

Integration testing across service boundaries is genuinely hard when those boundaries span multiple billion-dollar businesses that happen to share a parent company. Nobody woke up and decided to break Glue. It came that way from the factory.

This pattern isn't unique to AWS, and it isn't going away. Every major cloud provider—indeed, every major technology provider—is a portfolio of semi-autonomous teams whose roadmaps occasionally collide in their customers' environments.

The question isn't whether the org chart will produce another gap like this. It will. The question is what happens after the gap appears: does the response look like accountability—acknowledging the incompatibility before the deprecation deadline, not after—or does it look like a shrug and three paid alternatives?

As the article concludes: "Never attribute to malice what can be adequately explained by one very large org chart. Just don't forget to check the invoice."

This situation serves as a reminder that in the cloud era, customers are increasingly at the mercy of organizational dynamics they cannot see or control. When your production database breaks at 2 AM, the reason is academic—you need a fix. And when all the fixes are bad, that's not a technical problem. It's a trust problem.