Om din applikation hämtar stora resultat från Cloudflare D1 i en enda fråga bör du kontrollera den före den 4 november: från det datumet kommer frågor som returnerar mer än 50 MB att misslyckas. Ändringen gäller resultatets storlek, inte databasens storlek eller volymen på API-anropet; import och export via REST API fungerar som tidigare.
Vad är det som ändras?
Cloudflare meddelade begränsningen den 30 oktober 2026. Den nya regeln träder i kraft onsdagen den 4 november: om resultatet från en SQL-fråga överstiger 50 MB returnerar D1 felet D1 query result exceeded the maximum response size limit of 50 MB. Företaget uppger att tröskeln täcker den 99,999:e percentilen av frågorna i D1, vilket innebär att den överväldigande majoriteten av frågorna ligger under gränsen. Det är Cloudflares uppskattning för plattformen som helhet, inte en garanti för en enskild applikation.
Det är viktigt att skilja mellan frågeresultat och dataöverföring. Begränsningen gäller resultatet som en D1-fråga returnerar; import- och exportåtgärder via REST API är uttryckligen undantagna. Därför bör du i första hand kontrollera applikationsfrågor som läser många rader eller breda poster och sedan hämtar dem i sin helhet.
Varför stora resultat kan uppstå utan att märkas
Svarets storlek beror inte bara på antalet rader. En fråga med många kolumner kan ge ett stort resultat även med ett måttligt antal poster, särskilt om raderna innehåller långa texter eller andra omfattande värden. Konstruktionen SELECT * tar med alla kolumner, trots att den anropande koden kanske bara behöver några få. När en tabell växer kan en fråga som tidigare varit säker också passera gränsen.
Den praktiska slutsatsen är att du bör granska både engångsexporter för administration och återkommande operationer i applikationen – till exempel rapporthanterare, bakgrundsjobb och API-metoder som hämtar data för vidare bearbetning. Det här är scenarier att granska, inte ett påstående om att de alla nödvändigtvis påverkas.
Så förbereder du frågorna
I sitt meddelande rekommenderar Cloudflare att minska mängden data som returneras: välj de kolumner som behövs i stället för att använda SELECT * och dela upp stora urval i sidor med LIMIT och OFFSET. Det minskar storleken på varje enskilt svar och gör det möjligt att fördela bearbetningen över flera frågor.


- Hitta breda urval. Granska frågor med
SELECT *, utan begränsning av antalet rader eller med stora textfält. - Begränsa kolumnerna. Ange bara de kolumner som nästa steg i bearbetningen faktiskt behöver.
- Dela upp läsningen i mindre delar. Lägg till sidvis hämtning med
LIMITochOFFSET, enligt Cloudflares rekommendation, och bearbeta delarna i tur och ordning. - Kontrollera beteendet efter uppdelningen. Se till att applikationen sammanfogar resultaten korrekt och inte förutsätter att hela urvalet kommer i ett enda svar.
Om applikationen behöver hela datamängden för en separat export bör du kontrollera om export via REST API passar för uppgiften: Cloudflare meddelar särskilt att den nya gränsen inte gäller där. För applikationens vanliga logik ersätter detta undantag inte behovet av att se över stora SQL-svar.
Vem berörs av tidsfristen?
Tidsfristen berör direkt D1-användare vars frågor returnerar mer än 50 MB. Börja med att granska kod där resultatet läses in helt i minnet, skickas mellan komponenter eller sammanställs för en rapport. Om frågorna redan bara returnerar små sidor och nödvändiga fält kanske ingen särskild ändring behövs; beslutet bör baseras på den faktiska svarsstorleken för dina frågor.
En kontroll före den 4 november hjälper dig att upptäcka beroenden av ett enda stort svar innan begränsningen träder i kraft. Enligt Cloudflares uppskattning ligger tröskeln långt över den normala storleken för de flesta frågor. För system som påverkas är den mest direkta planen att minska mängden data som väljs, läsa den i mindre delar eller använda den avsedda vägen för export via REST API.