Cloudflare D1 : quand les limites gratuites bloquent les requêtes

Depuis le 1er septembre 2026, l’offre gratuite de Cloudflare D1 pose une vraie question de disponibilité en production. Dès qu’un compte atteint 5 millions de lignes lues ou 100,000 lignes écrites dans la journée, les requêtes D1 peuvent s’arrêter jusqu’à minuit UTC.

Cloudflare D1 : le quota n’a pas changé, son dépassement oui

Les volumes gratuits existaient déjà. Ce qui change, c’est ce qui se passe une fois la limite atteinte.

Avec Workers Free, dépasser l’un des deux plafonds journaliers conduit désormais D1 à rejeter les requêtes, qu’elles passent par la Workers Binding API ou par l’API REST. Cloudflare décrit des messages distincts pour les limites de lecture et d’écriture, et précise que les requêtes reprennent lorsque le quota est réinitialisé à 00:00 UTC. Les données stockées restent intactes. L’application, elle, peut ne plus être en mesure de les lire ni de les modifier.

Toute l’histoire tient dans cette nuance : un simple indicateur de consommation est devenu une frontière stricte de disponibilité.

Cloudflare envoie un e-mail lorsque la limite journalière est atteinte. Il explique l’incident, mais seulement une fois la base de données déjà indisponible. En production, il faut donc un budget et une alerte en amont, pas uniquement une explication après la panne. Le changelog D1 du 1er septembre détaille précisément le comportement en cas d’échec et le texte des erreurs.

Workers Paid n’est pas concerné par cet arrêt journalier. Un prototype qui reste largement sous les deux plafonds n’a pas forcément besoin de migrer aujourd’hui. En revanche, un produit en ligne qui dépend de D1 doit désormais traiter l’offre Free comme toute ressource assortie d’un seuil d’arrêt.

L’unité décisive, ce sont les lignes parcourues

Le quota de lecture ne correspond ni à 5 millions d’appels API ni à 5 millions d’enregistrements renvoyés. Il porte sur 5 millions de lignes parcourues par la base de données pour répondre aux requêtes.

Imaginons qu’un filtre renvoie un seul client, sans index pertinent. Pour retrouver cet enregistrement, D1 peut devoir parcourir une table de 5,000 lignes. Exécutée 1,000 fois, cette requête consomme la totalité des 5 millions de lectures quotidiennes. Le résultat paraît minuscule ; le travail effectué en coulisses ne l’est pas.

Le calcul des écritures est plus direct. Une instruction INSERT, UPDATE ou DELETE comptabilise les lignes modifiées. Insérer 10 lignes revient donc à écrire 10 lignes. Les opérations de schéma telles que CREATE, ALTER et DROP peuvent elles aussi consommer à la fois des lectures et des écritures.

La taille d’une ligne ne change rien à ce compteur. Une ligne de 1 KB et une ligne de 100 KB valent chacune une ligne. C’est la forme de la requête qui fait évoluer le nombre de lectures.

Un index permet à D1 d’accéder directement aux enregistrements utiles au lieu de parcourir toute la table. En général, quelques écritures supplémentaires permettent ainsi de réduire bien davantage les lectures. Lorsqu’une colonne indexée est modifiée, D1 écrit la ligne de la table et au moins une ligne d’index. La bonne stratégie consiste donc à indexer les colonnes utilisées dans les filtres et jointures fréquents, pas toutes les colonnes sans discernement.

Le guide des index de Cloudflare propose un test simple. Faites précéder la requête coûteuse de EXPLAIN QUERY PLAN. Un plan qui affiche SCAN parcourt la table ; s’il affiche SEARCH ... USING INDEX, il utilise un index. Après l’ajout d’un index, exécutez PRAGMA optimize afin que le planificateur dispose de statistiques à jour.

Le calcul économique a changé

Workers Free coûte toujours $0. Ce qui a changé, c’est le risque : la facture maximale de la base de données reste nulle, mais celle-ci peut désormais cesser de servir l’application jusqu’à la fin de la journée UTC.

Workers Paid démarre à $5 par compte et par mois. L’arrêt journalier strict est remplacé par un volume mensuel inclus, puis une facturation du dépassement.

L’écart entre Free et Paid est plus important qu’il n’y paraît. Sur trente jours, atteindre chaque jour le plafond de lecture de Free représenterait 150 millions de lignes, soit seulement 0.6% des 25 milliards de lectures incluses avec Paid. Trente jours au plafond d’écriture de Free totaliseraient 3 millions de lignes, soit 6% des 50 millions incluses.

Pour beaucoup de petites applications, la première décision de passage au payant ne porte donc pas sur un dépassement facturé. Il s’agit d’acheter de la disponibilité pour $5. Les requêtes Workers, le CPU, le stockage D1 au-delà de 5 GB et les autres produits Cloudflare conservent leurs propres compteurs : $5 est un plancher, pas la promesse que le compte entier coûtera exactement $5. Notre analyse des tarifs Cloudflare montre où se séparent les coûts du compte et ceux des différents produits.

D1 ne facture ni le transfert de données ni le débit. Cela ne rend pas la panne de l’offre Free moins sévère ; cela signifie simplement que le trafic sortant n’entre pas dans ce calcul.

Quatre équipes, quatre décisions concrètes

Une personne seule à la tête d’un SaaS en production

Si la connexion, l’état de la facturation ou le tableau de bord client interroge D1, l’offre Free expose désormais la production à un risque d’indisponibilité. Commencez par repérer la journée normale la plus chargée, puis corrigez les parcours complets de table. Si l’application reste proche du plafond, le minimum de $5 coûtera moins cher que de devoir composer avec un nombre imprévisible d’heures sans accès à la base de données.

Concrètement, il ne s’agit pas de gagner davantage de capacité, mais de ne plus avoir à attendre minuit UTC dans le plan de reprise après incident.

Une agence qui gère plusieurs bases sur un même compte

Le libellé de la limite indique qu’elle s’applique au niveau du compte. Une agence doit donc inventorier toutes les bases D1 du compte Cloudflare, au lieu d’examiner un seul projet client avant de conclure que tout le compte est à l’abri.

Les métriques par base permettent d’identifier le projet le plus gourmand ; additionnez ensuite les totaux avant de définir le budget du compte. L’équipe d’exploitation dispose ainsi d’un chiffre commun dont elle peut assumer le suivi. Le parcours inefficace d’un projet ne doit pas provoquer une panne inexplicable sur un autre projet du même compte.

Un ingénieur backend à la recherche des lectures coûteuses

L’objectif est d’identifier la structure des requêtes, pas de supprimer des données au hasard. Dans l’objet meta de chaque requête, D1 renvoie rows_read et rows_written. Ces valeurs donnent le coût précis d’une exécution.

Cloudflare propose aussi des informations détaillées sur les requêtes via Wrangler et l’API GraphQL Analytics. Triez-les par nombre de lectures pour repérer les parcours répétés, examinez le plan, ajoutez l’index ciblé, puis mesurez de nouveau. Une seule modification réduit ainsi la consommation du quota et, généralement, la latence.

Un responsable d’exploitation qui lance des imports ou des synchronisations

Une synchronisation en masse peut consommer 100,000 écritures avant même que le trafic client ait pu utiliser la base de données. Répartissez une tâche non urgente sur plusieurs fenêtres de réinitialisation, ou passez le compte à Paid avant un import en production.

Ne comptez pas faire le ménage après avoir atteint le plafond d’écriture. DELETE est lui-même une opération d’écriture : lorsque le quota est épuisé, la requête de nettoyage peut donc rester bloquée jusqu’à la réinitialisation. L’enjeu est de préserver les écritures en temps réel pendant l’exécution du traitement par lots.

Définir le budget du quota avant l’arrivée de l’alerte

Voici une première règle exploitable. Il s’agit d’une consigne d’exploitation, pas d’une exigence de Cloudflare : fixez le budget de production à 80% du quota publié de l’offre Free. Le plafond opérationnel journalier est alors de 4 millions de lectures et 80,000 écritures, avec une réserve de 1 million de lectures et 20,000 écritures pour absorber les pics et le retard des mesures.

1. 1

   Mesurer une vraie journée

   Dans Cloudflare, ouvrez D1, sélectionnez chaque base de données, puis accédez à Metrics. La vue par défaut couvre les dernières 24 heures. Consultez suffisamment d’historique pour observer les jours de semaine ordinaires, les lancements, les imports et les pics de trafic. D1 conserve ces métriques pendant 31 jours.

2. 2

   Trouver la requête qui consomme les lignes

   Pendant les tests des parcours importants, consultez les valeurs meta.rows_read et meta.rows_written de chaque requête. Servez-vous des informations détaillées sur les requêtes pour classer les instructions fréquentes ou coûteuses. Exécutez EXPLAIN QUERY PLAN sur la pire requête en lecture et corrigez tout parcours complet avant de considérer le changement de forfait comme l’unique solution.

3. 3

   Déclencher l’alerte avant la limite stricte

   Planifiez un contrôle du compte avec l’API GraphQL Analytics, qui interroge les mêmes jeux de données que le tableau de bord. Alertez la personne responsable à 4 millions de lectures ou 80,000 écritures. L’e-mail envoyé par Cloudflare une fois la limite atteinte reste utile pour confirmer l’incident, mais il ne doit pas constituer le premier signal en production.

4. 4

   Décider maintenant du comportement en cas d’échec

   Déterminez ce que le Worker doit renvoyer si D1 lève une erreur de limite. Une lecture mise en cache peut rester utile si elle ne déclenche pas une nouvelle requête D1. Un parcours d’écriture exige une réponse d’indisponibilité explicite ou une file d’attente conçue à part. Ne lancez pas de tentatives en boucle face à un quota qui ne se rétablira pas avant minuit UTC ou un changement de forfait.

La documentation des métriques D1 désigne rowsRead et rowsWritten comme les champs GraphQL et confirme que le tableau de bord repose sur les mêmes données d’analyse. Une petite équipe dispose donc d’un parcours manuel dès aujourd’hui, puis d’un parcours automatisable lorsque la base de données devient assez importante pour justifier une astreinte.

Ce que la solution ne règle pas

Un index n’est pas gratuit. Il occupe de l’espace de stockage et ajoute des écritures lorsque les valeurs indexées changent. Créez uniquement les index qui éliminent les parcours coûteux, puis mesurez le nouvel équilibre. Si un compte approche déjà de la limite de 100,000 écritures, une indexation sans discernement peut produire le mauvais compromis.

Paid n’est pas illimité non plus. Le forfait inclut 25 milliards de lectures et 50 millions d’écritures par mois, puis facture le dépassement aux tarifs publiés. Le passage au forfait supérieur lève l’arrêt journalier de Free, généralement en quelques minutes, mais ne dispense pas de surveiller les mauvaises requêtes ni de prévoir le reste de la facture Workers. La page actuelle des tarifs D1 de Cloudflare est la référence chiffrée à conserver dans le runbook.

L’historique des sources comporte une subtilité utile. Une note de version D1 de janvier 2025 annonçait que l’application de ces limites commencerait le 10 février 2025. Le changelog plus récent, consacré précisément à cet événement, indique un démarrage le 1er septembre 2026. C’est cette page plus récente qui fait foi ici, puisqu’elle nomme directement le déploiement actuel. Voilà pourquoi un ancien résultat de recherche peut afficher une date différente.

Enfin, « les données stockées ne sont pas affectées » est une affirmation plus étroite que « le produit fonctionne ». Les données peuvent rester en sécurité tandis que toutes les routes qui en dépendent renvoient une erreur. La disponibilité est la conséquence métier.

Que faire lundi ?

Agissez cette semaine si une application destinée aux clients fonctionne avec Workers Free et interroge D1 pendant le traitement des requêtes. Commencez par mesurer, corrigez les parcours de table évidents, définissez l’alerte à 4 millions de lectures et 80,000 écritures, puis autorisez à l’avance le passage à Paid pour $5.

Vous pouvez attendre s’il s’agit d’un prototype jetable, si l’historique de 31 jours reste très en dessous du budget opérationnel et si des requêtes en échec pendant une journée n’auraient aucun effet sur les clients ni sur le chiffre d’affaires. Conservez tout de même l’alerte : le trafic comme la taille des tables font évoluer le nombre de lectures.

Cet arrêt journalier précis ne vous concerne pas si le compte utilise déjà Workers Paid ou si l’application n’interroge pas D1.

La décision du lundi est simple : ouvrez l’onglet D1 Metrics pour chaque base, relevez la journée la plus chargée du compte en lectures et en écritures, identifiez la requête responsable du parcours le plus important et autorisez une personne à effectuer la mise à niveau. Si, après correction de la requête, un pic normal dépasse encore 4 millions de lectures ou 80,000 écritures, passez le compte à Workers Paid le jour même.

Pour recevoir la prochaine évolution d’une plateforme sous la forme d’une décision opérationnelle, inscrivez-vous à la newsletter.