Aurora MySQL 3.14 Is Generally Available: Hybrid Post-Quantum TLS Key Exchange Needs Client Support Too, DELETE Gains RETURNING and Makes It a Reserved Word, and Row-Size Behavior Stays Older Than Community 8.0.46

On November 2, 2026, AWS announced that Amazon Aurora MySQL-Compatible Edition 3, the MySQL 8.0 line, now supports MySQL 8.0.46 as Aurora MySQL 3.14. The announcement says the release carries community MySQL fixes and Aurora-specific improvements, and that its headline addition is support for post-quantum TLS (PQ-TLS) key exchange. It is available in all AWS Regions where Aurora MySQL is available. One date needs care: the Aurora release notes list version 3.14.0 under the date 2026-10-26, so the engine was documented about a week before the "starting today" announcement.

The announcement is short, and the release notes explain what the post-quantum feature does. Aurora MySQL adds two hybrid key exchange groups, X25519MLKEM768 and SecP256r1MLKEM768, alongside the classical elliptic-curve groups for TLS 1.3 connections. Clients that support post-quantum key exchange automatically negotiate a quantum-resistant shared secret, and clients that do not keep using classical groups. So turning it on is not a setting you flip on the server. It happens only when the client library also supports these groups and uses TLS 1.3. To check what a session negotiated, run SHOW STATUS LIKE 'Aurora_ssl_named_group'.

The release notes list other changes that may matter more to operators. Minor version upgrades to 3.14 from version 3.08 or higher now complete faster, so the writer instance returns to service sooner, with no configuration change or opt-in. Single-table DELETE statements gain a RETURNING clause, which returns values from the deleted rows without a separate SELECT. Because RETURNING is now a reserved keyword, any identifier named returning must be quoted with backticks, and an unquoted one will fail to parse after the upgrade. A new CloudWatch metric, FTSCacheMemoryUsed, shows memory used by the InnoDB full-text search cache across all tables on an instance.

One compatibility choice is worth reading closely. Community MySQL 8.0.46 changed how it handles tables with many columns of certain kinds, so creating such a table can fail with ERROR 1118, "Row size too large," even though the same statement worked on earlier 8.0 releases. The release notes say Aurora MySQL 3.14.0 retains the older behavior, so those statements keep working as in 3.13.0 and earlier. That means the behavior of Aurora 3.14 differs from community 8.0.46 here, which matters if you test or migrate between the two.

The notes also list security fixes. The Advanced Audit log previously recorded the definer's user and host, not the calling client's, for statements run inside a SQL SECURITY DEFINER routine, and now records the invoking client. Prepared statements no longer create duplicate audit entries. A fix covers SET ROLE NONE not clearing a previous role's privileges in sessions that use write forwarding, which could allow operations that should have been denied. The release also lists fixes for two high-severity CVEs and a longer list of medium-severity ones. Teams that parse audit logs for compliance should expect the user and host values to change after the upgrade.

On rollout, AWS says you can upgrade during maintenance windows with automatic minor version upgrades, and that the AWS Organizations Upgrade Rollout Policy can phase upgrades across clusters. Upgrades can be in place or through snapshot restore. For a team, the practical checklist is short: check that client libraries negotiate the hybrid groups if PQ-TLS is the goal, search code for unquoted returning identifiers, review audit-log consumers, and test in a lower environment first. The announcement and notes give no figures for the speed of the faster upgrade or for any TLS overhead.