RDS for PostgreSQL 18 opens ssl_groups to post-quantum key agreement
Victoria Shinder2 min readAmazon RDS for PostgreSQL now supports post-quantum key exchange for TLS connections, AWS announced on 24 September. The mechanism is a single parameter: on RDS for PostgreSQL version 18 and higher, the ssl_groups parameter can now be modified, and customers can select key exchange groups from an RDS allow list to match their organisation's security standards.
ssl_groups is the PostgreSQL setting that controls which groups the server offers for the TLS key exchange - the step in which client and server agree on the secret that encrypts the rest of the session. Choosing a post-quantum or hybrid group protects the confidentiality of that session against an attacker who records the traffic today and later obtains a quantum computer capable of breaking classical key exchange. The announcement does not name the groups on the allow list, and it covers data in transit only; storage encryption and authentication are unaffected.
What it means
Post-quantum key exchange is arriving first in the places where recorded traffic has a long shelf life, and database connections are one of them. A session carrying personal data, financial records or credentials is exactly the kind of traffic worth storing for later decryption, which is the "harvest now, decrypt later" scenario that motivates early adoption.
The practical point is that the server offering a group is only half of the handshake. The client library must support the same group, or the connection falls back to whatever both sides share. Applications connect through libpq, JDBC drivers and language-specific clients whose TLS stacks vary widely in post-quantum support, so turning the parameter on without checking the clients may change nothing. The sensible sequence is to confirm which groups the application's drivers can negotiate, set ssl_groups to include a hybrid group alongside the existing ones, and verify on a real connection which group was actually used before tightening the list.
There is also a version gate worth noting: the capability starts at PostgreSQL 18. Teams on earlier major versions get another reason to plan the upgrade, and teams that care about the feature should put it on the checklist for that migration rather than assuming it arrives with a minor-version update.