Michael JohnsonEen query naar Cloudflare D1 die een resultaat van meer dan 50 MB oplevert, mislukt sinds 4 november 2026. Voor ontwikkelaars is het belangrijk te weten waarop deze wijziging betrekking heeft: het gaat om de omvang van het resultaat van één query, niet om de maximale databasegrootte. Import en export via de REST API vallen niet onder deze limiet. De manier waarop gegevens worden gelezen bepaalt dus of de werkwijze moet worden aangepast.
Wat is er precies beperkt?
Cloudflare beschreef de wijziging in een bericht van 30 oktober: een query met een resultaat van meer dan 50 MB geeft de foutmelding D1 query result exceeded the maximum response size limit of 50 MB. De limiet is ingegaan op 4 november 2026. De D1-documentatie vermeldt eveneens een limiet voor de omvang van queryresultaten; een database kan ondertussen maximaal 10 GB bevatten op een betaald abonnement of 500 MB op het gratis abonnement.
Het gaat om verschillende niveaus: de opslag bepaalt hoeveel gegevens de database kan bevatten, terwijl de resultaatlimiet bepaalt hoeveel gegevens één query kan teruggeven. Een database kan dus veel meer dan 50 MB aan gegevens bevatten en toch toegankelijk blijven als je de gegevens in delen uitleest. Zelfs een query op een kleine database kan de limiet overschrijden als die veel brede rijen of grote tekst- en binaire velden selecteert.
In de aankondiging van Cloudflare over de limiet geeft het bedrijf aan dat de drempel het 99,999e percentiel van D1-query’s dekt. Dit is een schatting van de verdeling van query’s door de leverancier; voor een controle in de praktijk is het belangrijker om de concrete antwoorden van de applicatie te meten en query’s op te sporen die grote hoeveelheden gegevens teruggeven.
Waarom is export via de REST API een apart geval?
Een applicatiequery krijgt doorgaans het resultaat van een SQL-uitvoering terug en geeft dat door aan de aanroepende code. Het importeren en exporteren van een database via de REST API zijn andere bewerkingen: Cloudflare geeft afzonderlijk aan dat die niet onder de nieuwe drempel vallen en op dezelfde manier blijven werken. Een fout bij een grote selectie betekent dus niet dat je geen grote hoeveelheid gegevens uit de database kunt exporteren.
In de praktijk helpt dit onderscheid je de juiste route te kiezen. Heeft de applicatie alle records nodig om ze weer te geven, te verwerken of in een rapport op te nemen, splits het uitlezen dan op in delen. Is het doel om gegevens over te zetten of te exporteren, controleer dan of export via de REST API geschikt is in plaats van te proberen de hele database met één SQL-antwoord op te halen.
Hoe verklein je het antwoord zonder benodigde gegevens te verliezen?
De eerste stap is om overbodige kolommen weg te laten. Gebruik in plaats van SELECT * alleen de velden die nodig zijn voor de huidige bewerking. Dat verkleint het antwoord, vooral als de tabel lange beschrijvingen, JSON- of BLOB-waarden bevat.
De tweede stap is om rijen in delen uit te lezen met LIMIT en OFFSET, zoals Cloudflare aanbeveelt. Een interface kan bijvoorbeeld de volgende pagina ophalen terwijl de gebruiker scrolt, en een batchtaak kan de delen afzonderlijk verwerken. Voeg een stabiele sortering toe, bijvoorbeeld op een unieke identificatiecode: zonder die kan de paginering verschuiven als de gegevens tussen query’s veranderen.
Bij lange exports is het ook verstandig een controlepunt van de laatst verwerkte record op te slaan. Zo kan een taak na een storing worden hervat zonder de hele gegevensset opnieuw te verwerken. De precieze aanpak hangt af van de applicatie; het kernprincipe is om de omvang van elk antwoord te beperken en niet te vertrouwen op één query die de volledige gegevensset teruggeeft.
Wat moet je in de applicatie controleren?
Begin met query’s die grote lijsten teruggeven: exports voor rapporten, beheerschermen, achtergrondtaken en API-routes die arrays met rijen opleveren. Leg tijdelijk de omvang van het geserialiseerde antwoord vast, of noteer het aantal en de grootte van de geselecteerde velden. Controleer vervolgens de maximaal verwachte omvang, niet alleen de kleine testgegevens die je doorgaans gebruikt.
Als de applicatie na de wijziging een foutmelding krijgt, brengt de D1-documentatie die specifiek in verband met resultaten groter dan 50 MB. Het advies is om alleen benodigde kolommen te selecteren of de resultaten te pagineren. Zo kun je een probleem met de antwoordgrootte onderscheiden van beperkingen op uitvoeringstijd, geheugen of databasebeschikbaarheid; die hebben andere foutmeldingen en oorzaken.
De conclusie voor teams is eenvoudig: voor gewone, korte selecties zijn waarschijnlijk geen aanpassingen nodig, maar grote leesopdrachten kun je het beste in delen verwerken. De limiet verhindert niet dat je een grotere database opslaat en blokkeert export via de REST API niet; wel moet je queries zo ontwerpen dat elk afzonderlijk antwoord binnen 50 MB blijft.
