Michael JohnsonDepuis le 4 novembre 2026, une requête adressée à Cloudflare D1 échoue si elle renvoie un résultat de plus de 50 Mo. Pour les développeurs, il est important de bien cerner la portée de ce changement : il concerne la taille du résultat d’une requête donnée, et non la taille maximale de la base. L’import et l’export via l’API REST ne sont pas soumis à cette limite. C’est donc la méthode de lecture des données qui détermine s’il faut modifier le flux de travail.
Qu’est-ce qui est exactement limité ?
Dans une publication du 30 octobre, Cloudflare a annoncé cette limite : une requête dont le résultat dépasse 50 Mo renvoie l’erreur D1 query result exceeded the maximum response size limit of 50 MB. La limite entre en vigueur le 4 novembre 2026. La documentation D1 précise également qu’il s’agit d’une limite portant sur la taille du résultat d’une requête ; une base peut, quant à elle, stocker jusqu’à 10 Go avec l’offre payante ou 500 Mo avec l’offre gratuite.
Il s’agit de deux niveaux distincts : le stockage définit le volume de données dans la base, tandis que la limite de résultat détermine la quantité de données qu’une seule requête peut renvoyer. Une base peut donc contenir bien plus de 50 Mo de données tout en restant accessible par lectures fractionnées. À l’inverse, même une requête sur une petite base peut dépasser la limite si elle sélectionne de nombreuses lignes volumineuses ou de grands champs textuels et binaires.
Dans son annonce, Cloudflare indique que le seuil couvre le 99,999e percentile des requêtes D1. Il s’agit d’une estimation de la distribution des requêtes fournie par le prestataire ; pour vérifier le comportement d’une application, le plus important est de mesurer ses réponses et de repérer les requêtes qui renvoient de grands volumes de données.
Pourquoi l’export via l’API REST est-il un cas à part ?
Une application reçoit généralement le résultat d’une requête SQL et le transmet au code appelant. L’import et l’export d’une base via l’API REST sont des opérations différentes : Cloudflare précise qu’ils ne sont pas soumis au nouveau seuil et continuent de fonctionner comme auparavant. Ainsi, l’échec d’une requête volumineuse ne signifie pas qu’il est impossible d’exporter un grand volume de données depuis la base.
En pratique, cette distinction aide à choisir la bonne méthode. Si l’application a besoin de toutes les entrées pour les afficher, les traiter ou produire un rapport, fractionnez la lecture en lots. Si l’objectif est de transférer ou d’exporter les données, examinez la possibilité d’utiliser l’export via l’API REST plutôt que d’essayer de récupérer toute la base dans une seule réponse SQL.
Comment réduire la réponse sans perdre les données nécessaires ?
La première étape consiste à supprimer les colonnes inutiles. Au lieu d’utiliser SELECT *, indiquez uniquement les champs nécessaires à l’opération en cours. Cela réduit le volume de la réponse, en particulier si la table contient de longues descriptions, des données JSON ou des valeurs BLOB.
La deuxième étape consiste à lire les lignes par lots à l’aide de LIMIT et OFFSET, comme le recommande Cloudflare. Par exemple, une interface peut récupérer la page suivante au fil du défilement, tandis qu’une tâche par lots traite séparément chaque segment. Ajoutez un tri stable, par exemple sur un identifiant unique : sans cela, les limites entre les pages peuvent se décaler si les données changent entre les requêtes.
Pour les exports de longue durée, il est également conseillé de conserver un point de reprise indiquant le dernier enregistrement traité. La tâche peut ainsi reprendre après une panne sans retraiter l’ensemble des données. La méthode dépend de l’application ; le principe essentiel consiste à limiter la taille de chaque réponse plutôt qu’à compter sur une seule requête qui renvoie tout le jeu de données.
Que vérifier dans l’application
Commencez par les requêtes qui renvoient de longues listes : exports de rapports, écrans d’administration, tâches en arrière-plan et routes d’API qui renvoient des tableaux de lignes. Mesurez temporairement le volume de la réponse sérialisée, ou le nombre et la taille des champs sélectionnés. Vérifiez ensuite le volume maximal attendu, et pas seulement celui d’un petit jeu de données de test habituel.
Si l’application renvoie une erreur après l’entrée en vigueur du changement, la documentation D1 l’associe précisément aux résultats de plus de 50 Mo et recommande de sélectionner les colonnes nécessaires ou de paginer les résultats. Cela permet de distinguer un problème de taille de réponse des limites de durée d’exécution, de mémoire ou de disponibilité de la base, qui ont d’autres causes et produisent d’autres erreurs.
En résumé, les requêtes courtes habituelles ne nécessiteront probablement aucun changement, tandis que les lectures volumineuses devront être traitées par lots. Cette limite n’empêche pas de stocker une base plus grande et ne bloque pas l’export via l’API REST ; elle impose de concevoir les requêtes pour que chaque réponse reste sous les 50 Mo.
