Aurora MySQL 3.14 est disponible : échange de clés TLS post-quantique hybride (le client doit aussi le prendre en charge), RETURNING sur DELETE devenu mot réservé, et comportement de taille de ligne resté ancien face à MySQL 8.0.46

Le 2 novembre 2026, AWS a annoncé qu'Amazon Aurora MySQL, édition compatible 3 (la branche MySQL 8.0), prend désormais en charge MySQL 8.0.46 sous le nom d'Aurora MySQL 3.14. L'annonce dit que la version comporte des correctifs de MySQL communautaire et des améliorations propres à Aurora, et que son ajout principal est la prise en charge de l'échange de clés TLS post-quantique (PQ-TLS). Elle est disponible dans toutes les régions AWS où Aurora MySQL existe. Une date demande de la prudence : les notes de version d'Aurora classent la 3.14.0 à la date du 2026-10-26, de sorte que le moteur était documenté environ une semaine avant l'annonce « à partir d'aujourd'hui ».

L'annonce est courte, et ce sont les notes de version qui expliquent ce que fait la fonction post-quantique. Aurora MySQL ajoute deux groupes d'échange de clés hybrides, X25519MLKEM768 et SecP256r1MLKEM768, aux côtés des groupes classiques à courbes elliptiques pour les connexions TLS 1.3. Les clients qui prennent en charge l'échange de clés post-quantique négocient automatiquement un secret partagé résistant aux ordinateurs quantiques, et ceux qui ne le font pas continuent d'utiliser les groupes classiques. L'activer n'est donc pas un réglage à basculer côté serveur : cela se produit seulement si la bibliothèque cliente prend aussi en charge ces groupes et utilise TLS 1.3. Pour voir ce qu'une session a négocié, exécutez SHOW STATUS LIKE 'Aurora_ssl_named_group'.

Les notes listent d'autres changements qui peuvent compter davantage pour les exploitants. Les mises à niveau mineures vers la 3.14 depuis la version 3.08 ou plus récente se terminent désormais plus vite, si bien que l'instance d'écriture revient plus tôt en service, sans changement de configuration ni adhésion. Les instructions DELETE sur une seule table gagnent une clause RETURNING, qui renvoie les valeurs des lignes supprimées sans SELECT séparé. Comme RETURNING devient un mot réservé, tout identifiant nommé returning doit être mis entre accents graves, et un identifiant sans guillemets échouera à l'analyse après la mise à niveau. Une nouvelle métrique CloudWatch, FTSCacheMemoryUsed, indique la mémoire utilisée par le cache de recherche plein texte d'InnoDB sur toutes les tables d'une instance.

Un choix de compatibilité mérite une lecture attentive. MySQL communautaire 8.0.46 a changé la gestion des tables ayant beaucoup de colonnes de certains types, de sorte que créer une telle table peut échouer avec l'ERROR 1118 « Row size too large », alors que la même instruction fonctionnait dans les versions 8.0 antérieures. Les notes disent qu'Aurora MySQL 3.14.0 conserve l'ancien comportement, ces instructions continuant donc de fonctionner comme en 3.13.0 et avant. Sur ce point, Aurora 3.14 diffère donc de la version communautaire 8.0.46, ce qui compte si vous testez ou migrez entre les deux.

Les notes listent aussi des correctifs de sécurité. Le journal Advanced Audit enregistrait auparavant l'utilisateur et l'hôte du définisseur, et non ceux du client appelant, pour les instructions exécutées dans une routine SQL SECURITY DEFINER ; il enregistre désormais le client qui appelle. Les instructions préparées ne créent plus d'entrées d'audit en double. Un correctif traite SET ROLE NONE qui n'effaçait pas les privilèges d'un rôle précédent dans les sessions utilisant la redirection d'écriture, ce qui pouvait autoriser des opérations qui auraient dû être refusées. La version liste aussi des correctifs pour deux CVE de gravité élevée et une liste plus longue de gravité moyenne. Les équipes qui analysent les journaux d'audit pour la conformité doivent s'attendre à ce que les valeurs d'utilisateur et d'hôte changent après la mise à niveau.

Pour le déploiement, AWS dit que l'on peut mettre à niveau pendant les fenêtres de maintenance avec les mises à niveau mineures automatiques, et que la politique de déploiement des mises à niveau d'AWS Organizations peut étaler les mises à niveau par phases sur les clusters. Elles peuvent se faire sur place ou par restauration d'un instantané. Pour une équipe, la liste de contrôle est courte : vérifier que les bibliothèques clientes négocient les groupes hybrides si le PQ-TLS est l'objectif, chercher dans le code les identifiants returning sans accents graves, revoir les consommateurs des journaux d'audit, et tester d'abord dans un environnement inférieur. L'annonce et les notes ne donnent aucun chiffre sur la vitesse de la mise à niveau accélérée ni sur un éventuel surcoût TLS.