Michael JohnsonEn spørring til Cloudflare D1 som returnerer et resultat på over 50 MB, vil feile fra 4. november 2026. For utviklere er det viktig å forstå hva endringen avgrenser: Det gjelder størrelsen på resultatet fra én enkelt spørring, ikke den maksimale størrelsen på databasen. Import og eksport via REST API er ikke omfattet av denne grensen, så måten dataene leses på, avgjør om arbeidsflyten må endres.
Hva er det egentlig som begrenses?
Cloudflare beskrev endringen i et innlegg datert 30. oktober: En spørring med et resultat på over 50 MB returnerer feilen D1 query result exceeded the maximum response size limit of 50 MB. Grensen trer i kraft 4. november 2026. I D1-dokumentasjonen er den også oppført som en begrensning på størrelsen på spørringsresultatet. Databasen kan samtidig lagre opptil 10 GB på en betalt plan eller 500 MB på gratisplanen.
Dette er to ulike nivåer: Lagringsgrensen angir datamengden i databasen, mens resultatgrensen angir hvor mye data én spørring kan returnere. En database kan derfor inneholde langt mer enn 50 MB med data og fortsatt være tilgjengelig for lesing i deler. Samtidig kan en spørring mot en liten database overskride grensen hvis den henter mange brede rader eller store tekst- og binærfelt.
I kunngjøringen av D1-grensen oppgir Cloudflare at terskelen dekker 99,999-persentilen av D1-spørringer. Dette er leverandørens anslag for fordelingen av spørringer. Når du vurderer hvordan grensen påvirker en app, er det viktigere å måle de faktiske svarene og finne spørringene som returnerer store datamengder.
Hvorfor er eksport via REST API et eget tilfelle?
En appspørring mottar vanligvis resultatet av en SQL-operasjon og sender det videre til koden som kaller den. Import og eksport av databaser via REST API er andre operasjoner: Cloudflare presiserer at de ikke omfattes av den nye terskelen og fortsetter som før. En feil ved en stor spørring betyr altså ikke at store datamengder ikke kan eksporteres fra databasen.
I praksis gjør dette skillet det enklere å velge riktig fremgangsmåte. Hvis appen trenger alle oppføringene for visning, behandling eller rapportering, bør lesingen deles opp i mindre deler. Hvis målet er å flytte eller eksportere data, bør du undersøke eksport via REST API i stedet for å forsøke å hente hele databasen i ett SQL-svar.
Hvordan redusere svaret uten å miste nødvendige data?
Første steg er å utelate unødvendige kolonner. I stedet for SELECT * angir du bare feltene som trengs for den aktuelle operasjonen. Dette reduserer svarstørrelsen, særlig hvis tabellen inneholder lange beskrivelser, JSON eller BLOB-verdier.
Deretter kan du lese rader i mindre deler med LIMIT og OFFSET, slik Cloudflare anbefaler. Et grensesnitt kan for eksempel hente neste side etter hvert som brukeren blar, mens en batchjobb behandler delene separat. Bruk en stabil sortering, for eksempel etter en unik identifikator: Uten dette kan sidegrensene forskyves hvis dataene endres mellom spørringene.
For langvarige eksporter bør du også lagre et kontrollpunkt for den sist behandlede oppføringen. Da kan jobben fortsette etter et avbrudd uten å måtte behandle hele datasettet på nytt. Den konkrete løsningen avhenger av appen; hovedprinsippet er å begrense størrelsen på hvert svar, ikke å basere seg på én spørring som returnerer hele datasettet.
Dette bør du kontrollere i appen
Begynn med spørringer som returnerer store lister: rapporteksporter, administrasjonssider, bakgrunnsjobber og API-ruter som sender ut matriser med rader. Registrer midlertidig størrelsen på det serialiserte svaret, eller antallet og størrelsen på de valgte feltene. Kontroller deretter den største forventede datamengden, ikke bare små, vanlige testdatasett.
Hvis appen får en feil etter endringen, knytter D1-dokumentasjonen den til resultater på over 50 MB og anbefaler å velge nødvendige kolonner eller dele resultatet opp i sider. Dette gjør det mulig å skille en feil på grunn av svarstørrelse fra begrensninger knyttet til kjøretid, minne eller databasetilgjengelighet, som har andre feilmeldinger og årsaker.
Konklusjonen for teamet er enkel: Vanlige, små spørringer vil sannsynligvis ikke kreve endringer, mens store lesinger bør legges om til behandling i mindre deler. Grensen hindrer verken lagring av større databaser eller eksport via REST API; den betyr at spørringene må utformes slik at hvert enkelt svar holder seg under 50 MB.
