Michael JohnsonEn fråga till Cloudflare D1 som returnerar ett resultat större än 50 MB misslyckas från och med den 4 november 2026. För utvecklare är det viktigt att förstå vad förändringen omfattar: det handlar om storleken på resultatet från en enskild fråga, inte om databasens maximala storlek. Import och export via REST API omfattas inte av gränsen, så sättet data läses på avgör om arbetsflödet behöver ändras.
Vad är det egentligen som begränsas?
Cloudflare beskrev ändringen i ett inlägg den 30 oktober: en fråga vars resultat överstiger 50 MB returnerar felet D1 query result exceeded the maximum response size limit of 50 MB. Gränsen började gälla den 4 november 2026. I D1-dokumentationen anges också gränsen för frågeresultat; databaser kan samtidigt lagra upp till 10 GB med betalplanen eller 500 MB med gratisplanen.
Det handlar om två olika nivåer: lagringsgränsen anger hur mycket data databasen kan innehålla, medan resultatgränsen anger hur mycket data en enskild fråga kan returnera. Därför kan en databas innehålla betydligt mer än 50 MB och ändå vara läsbar i mindre delar. Samtidigt kan en fråga mot en liten databas överskrida gränsen om den väljer många breda rader eller stora text- och binärfält.
I Cloudflares tillkännagivande om gränsen uppger företaget att tröskeln täcker den 99,999:e percentilen av D1-frågorna. Det är en uppskattning av frågefördelningen från leverantören; för praktisk kontroll är det viktigare att mäta programmets faktiska svar och hitta frågor som returnerar stora datamängder.
Varför är export via REST API ett separat fall?
En fråga från ett program får vanligtvis SQL-resultatet och skickar det vidare till den anropande koden. Import och export av databaser via REST API är andra typer av operationer: Cloudflare uppger särskilt att de inte omfattas av den nya gränsen och fortsätter att fungera som tidigare. Ett fel vid en stor urvalsfråga betyder alltså inte att det är omöjligt att exportera stora datamängder från databasen.
I praktiken hjälper den här skillnaden dig att välja rätt väg. Om programmet behöver alla poster för visning, bearbetning eller rapportering bör läsningen delas upp i mindre omgångar. Om målet är att flytta eller exportera data bör du undersöka export via REST API i stället för att försöka få hela databasen i ett enda SQL-svar.
Hur minskar man svarets storlek utan att förlora nödvändiga data?
Det första steget är att ta bort onödiga kolumner. I stället för SELECT * anger du bara de fält som behövs för den aktuella operationen. Det minskar svarsstorleken, särskilt om tabellen innehåller långa beskrivningar, JSON eller BLOB-värden.
Det andra steget är att läsa rader i mindre omgångar med LIMIT och OFFSET, vilket Cloudflare rekommenderar. Ett gränssnitt kan till exempel hämta nästa sida medan användaren rullar, och ett batchjobb kan behandla poster i separata omgångar. Lägg till en stabil sortering, till exempel efter en unik identifierare: utan den kan sidgränserna förskjutas om data ändras mellan frågorna.
Vid långvariga exporter är det också bra att spara en kontrollpunkt för den senast behandlade posten. Då kan jobbet återupptas efter ett avbrott utan att hela datamängden behöver behandlas igen. Den exakta lösningen beror på programmet; grundprincipen är att begränsa storleken på varje svar i stället för att förlita sig på en enda fråga som returnerar hela datamängden.
Vad bör kontrolleras i programmet?
Börja med frågor som returnerar stora listor: rapportexporter, administrationsvyer, bakgrundsjobb och API-rutter som skickar tillbaka matriser med rader. Logga tillfälligt den serialiserade svarsstorleken eller antalet och storleken på de valda fälten. Kontrollera sedan den största förväntade datamängden, inte bara vanliga små testdata.
Om programmet börjar ge fel efter ändringen kopplar D1-dokumentationen det till resultat större än 50 MB och rekommenderar att endast nödvändiga kolumner väljs eller att resultatet delas upp i sidor. På så sätt går det att skilja ett problem med svarsstorleken från begränsningar i körtid, minne eller databasens tillgänglighet: de har andra felmeddelanden och orsaker.
Slutsatsen för teamet är enkel: vanliga, korta urval behöver sannolikt inte ändras, medan stora läsningar bör övergå till bearbetning i mindre omgångar. Gränsen hindrar inte lagring av större databaser och stoppar inte export via REST API; den innebär att frågor bör utformas så att varje enskilt svar håller sig under 50 MB.
