Cloudflare D1 imposera une limite aux résultats des requêtes : quoi vérifier avant le 4 novembre

Si votre application récupère de gros résultats depuis Cloudflare D1 en une seule requête, vérifiez-la avant le 4 novembre : à partir de cette date, toute requête renvoyant plus de 50 Mo échouera. Cette modification concerne la taille du résultat, et non celle de la base de données ou le volume d’une requête à l’API ; les importations et exportations via l’API REST conservent leur comportement actuel.

Ce qui change exactement

Cloudflare a annoncé cette limite le 30 octobre 2026. La nouvelle règle entrera en vigueur le mercredi 4 novembre : si le résultat d’une requête SQL dépasse 50 Mo, D1 renverra l’erreur D1 query result exceeded the maximum response size limit of 50 MB. Selon l’entreprise, ce seuil couvre le 99,999e percentile des requêtes D1, ce qui signifie que l’immense majorité des requêtes reste en dessous de la limite. Il s’agit d’une estimation de Cloudflare pour sa plateforme, et non d’une garantie pour une application donnée.

Il est important de distinguer le résultat d’une requête du transfert de données. La limite concerne le résultat renvoyé par une requête D1 ; les opérations d’importation et d’exportation via l’API REST sont explicitement exclues de cette règle. Il faut donc avant tout vérifier les requêtes de l’application qui lisent de nombreuses lignes ou des enregistrements volumineux, puis les récupèrent dans leur intégralité.

Pourquoi un résultat volumineux peut passer inaperçu

Le volume de la réponse ne dépend pas uniquement du nombre de lignes. Une requête comportant de nombreuses colonnes peut produire un résultat volumineux même avec un nombre modéré d’enregistrements, notamment si les lignes contiennent de longs textes ou d’autres valeurs de grande taille. La clause SELECT * ajoute toutes les colonnes, même si l’appelant n’en a besoin que de quelques-unes. La croissance d’une table peut également faire franchir le seuil à une requête auparavant sans risque.

Conséquence pratique : vérifiez non seulement les extractions ponctuelles destinées à l’administration, mais aussi les opérations régulières de l’application — par exemple les gestionnaires de rapports, les tâches en arrière-plan et les méthodes d’API qui rassemblent des données pour les traiter ensuite. Ce sont des scénarios à auditer, et non l’affirmation qu’ils seront tous concernés.

Comment préparer les requêtes

Dans son avis, Cloudflare recommande de réduire le jeu de résultats renvoyé : sélectionnez les colonnes nécessaires au lieu d’utiliser SELECT * et répartissez les grandes extractions en pages avec LIMIT et OFFSET. Cette approche réduit le volume de chaque réponse et permet de répartir le traitement sur plusieurs requêtes.

1. Repérez les extractions trop larges. Passez en revue les requêtes utilisant SELECT *, sans limite sur le nombre de lignes ou contenant de grands champs textuels.
2. Réduisez les colonnes sélectionnées. Énumérez uniquement les colonnes réellement nécessaires à l’étape de traitement suivante.
3. Répartissez la lecture en lots. Ajoutez une pagination avec LIMIT et OFFSET, comme le recommande Cloudflare, et traitez les lots successivement.
4. Vérifiez le comportement après la pagination. Assurez-vous que l’application assemble correctement les résultats et ne dépend pas de la récupération de l’intégralité du jeu de résultats en une seule réponse.

Si l’application a besoin de l’ensemble complet des données pour une extraction distincte, vérifiez si l’opération d’exportation via l’API REST convient à cette tâche : Cloudflare précise que la nouvelle limite ne s’y applique pas. Pour la logique habituelle de l’application, cette exception ne dispense pas de revoir les réponses SQL volumineuses.

Qui est concerné par l’échéance

L’échéance concerne directement les utilisateurs de D1 dont les requêtes renvoient plus de 50 Mo. Il faut d’abord vérifier le code qui charge le résultat entier en mémoire, le transmet entre composants ou le produit pour un rapport. Si les requêtes renvoient déjà de petites pages et uniquement les champs nécessaires, aucune modification particulière ne sera peut-être requise ; la décision doit se fonder sur la taille réelle des réponses de vos requêtes.

Une vérification avant le 4 novembre permet de repérer toute dépendance à une réponse unique volumineuse avant l’entrée en vigueur de la limite. Selon l’estimation de Cloudflare, le seuil reste bien au-delà du volume habituel pour la plupart des requêtes ; pour les systèmes concernés, le plan le plus direct consiste à réduire les données sélectionnées, à les lire par lots ou à utiliser la voie prévue pour les extractions via l’API REST.