L'ajout le plus directement exploitable côté base de données est DB::usingWritePdo(). Cette méthode exécute une chaîne de requêtes sur la connexion d'écriture pendant un callback, puis rétablit le réglage précédent, y compris si le callback lève une exception.

<?php
use Illuminate\Support\Facades\DB;

$posts = DB::usingWritePdo(
    fn () => User::query()
        ->where('email', $email)
        ->first()
        ?->posts()
        ->whereNull('published_at')
        ->get()
);

Elle couvre un cas difficile à repérer : un modèle est chargé depuis la connexion d'écriture, puis une requête sur sa relation part vers une réplique de lecture. Cette possibilité concerne notamment la lecture d'une commande avec son statut actuel, la vérification d'un stock après une correction ou le chargement des permissions après un changement de rôle.

Le middleware PreventStaleDatabaseReads traite la cohérence entre deux requêtes successives. Après une écriture sur la connexion par défaut, Laravel place un horodatage dans la session. Pendant les deux secondes suivantes, les lectures de l'utilisateur passent par la connexion d'écriture. Un groupe de routes peut demander dix secondes avec PreventStaleDatabaseReads::for(10). La fonctionnalité exige une session et ne concerne que l'utilisateur qui a effectué l'écriture. Elle ne convient donc pas aux API sans état et n'apporte rien à une application qui n'utilise qu'une seule connexion.

La validation accepte maintenant les valeurs flottantes dans la condition where de Rule::unique(). Une règle peut ainsi intégrer une valeur comme 19.99 lorsqu'une référence et un prix forment ensemble la clé logique d'unicité. Cette évolution ne remplace pas une contrainte de base de données. Un index adapté reste nécessaire pour garantir cette règle au niveau du stockage.

Eloquent corrige la gestion des alias ofMany() dans les closures et les agrégats associés aux relations one-of-many qui se référencent elles-mêmes. Ces relations servent à sélectionner un seul enregistrement selon un critère, par exemple le dernier prix applicable ou le statut courant. Les applications qui utilisent ces constructions devraient ajouter des tests de non-régression avant la mise à jour.

Les itérateurs lazy() et lazyById() libèrent désormais le bloc précédent au fil du traitement. Le changement limite la mémoire conservée lors de gros exports, de mises à jour d'inventaire, de traitements historiques, de jobs en arrière-plan et de scripts de migration. La consommation ne reste pas forcément constante si le code conserve chaque modèle traité.

Le verrou de cache des Unique Jobs est maintenant supprimé lorsque l'envoi d'un job planifié échoue. Une nouvelle tentative ne reste donc pas bloquée par un verrou abandonné. Le cas concerne notamment les rapports périodiques, les synchronisations externes et les imports. Les chemins d'échec doivent être vérifiés avec la configuration Queue et cache de chaque application.

La version corrige aussi les valeurs flottantes renvoyées par collection mode(), les règles de comparaison de dates recevant des valeurs qui ne sont pas des dates et certaines modifications de schéma SQLite avec des clés étrangères ou des noms de tables entre guillemets. Le traitement des Unique Broadcast Jobs ignorés progresse. Les arrêts inattendus de workers peuvent compter comme des exceptions pour les queued listeners, mailables et notifications explicitement concernés. Le cache des routes est amélioré lorsque les routes de santé sont générées sur une machine puis utilisées sur une autre. Le clonage des relations et le comportement de requêtes SQL reçoivent d'autres corrections.

Pour préparer la mise à jour, php artisan --version affiche la version installée et composer show laravel/framework permet de vérifier la contrainte du framework. La commande composer update laravel/framework met le paquet à jour. Les dépendances liées doivent être contrôlées avant l'opération, puis php artisan test doit être exécuté. Les tests doivent couvrir la relecture immédiate après une écriture, le chargement de relations après modification, les API sans session, les échecs de jobs planifiés, les grands traitements avec lazy() ou lazyById() et les requêtes ofMany(). Après le déploiement en préproduction puis en production, il faut surveiller les requêtes, les erreurs de queue et les journaux. Les notes de version officielles de Laravel, l'aperçu de Laravel News et la documentation Laravel 13.x constituent les références indiquées.