Michael JohnsonCloudflare D1 -kysely, joka palauttaa yli 50 Mt:n tuloksen, epäonnistuu 4. marraskuuta 2026 alkaen. Kehittäjän kannalta olennaista on muutoksen rajaus: kyse on yksittäisen kyselyn tuloksen koosta, ei tietokannan enimmäiskoosta. Tuonti ja vienti REST API:n kautta eivät kuulu tämän rajan piiriin, joten tietojen lukutapa ratkaisee, tarvitseeko työnkulkua muuttaa.
Mitä tarkalleen ottaen rajoitetaan?
Cloudflare kuvasi muutoksen 30. lokakuuta julkaistussa tiedotteessa: kysely, jonka tulos ylittää 50 Mt, palauttaa virheen D1 query result exceeded the maximum response size limit of 50 MB. Rajoitusta aletaan soveltaa 4. marraskuuta 2026. D1-dokumentaatiossa raja määritellään samoin kyselyn tuloksen kokoon liittyväksi rajoitukseksi; tietokantaan voi silti tallentaa maksullisella tilauksella enintään 10 Gt ja maksuttomalla 500 Mt.
Nämä ovat eri asioita: tallennustila määrittää tietokantaan mahtuvan datan määrän, kun taas tulosraja määrittää, kuinka paljon dataa yksi kysely voi palauttaa. Tietokanta voi siis sisältää selvästi yli 50 Mt dataa ja olla silti luettavissa osissa. Toisaalta pienestäkin tietokannasta tehty kysely voi ylittää rajan, jos se valitsee paljon leveitä rivejä tai suuria teksti- ja binäärikenttiä.
Rajoitusta koskevassa Cloudflaren tiedotteessa yritys kertoo kynnyksen kattavan D1-kyselyiden 99,999. persentiilin. Tämä on palveluntarjoajan esittämä arvio kyselyiden jakaumasta; sovelluksen kannalta tärkeämpää on mitata todellisten vastausten kokoa ja tunnistaa kyselyt, jotka palauttavat suuria datamääriä.
Miksi vienti REST API:n kautta on eri asia?
Sovellus yleensä saa SQL-kyselyn tuloksen ja välittää sen kutsuvalle koodille. Tietokannan tuonti ja vienti REST API:n kautta ovat eri toimintoja: Cloudflare kertoo erikseen, etteivät ne kuulu uuden rajan piiriin ja että ne toimivat entiseen tapaan. Siksi suuren haun epäonnistuminen ei tarkoita, ettei tietokannasta voisi viedä suurta datamäärää.
Käytännössä tämä ero auttaa valitsemaan oikean tavan. Jos sovellus tarvitsee kaikki tietueet näyttämistä, käsittelyä tai raportointia varten, jaa luku osiin. Jos tarkoituksena on siirtää tai viedä dataa, tarkista REST API:n vientitoiminto sen sijaan, että yrittäisit saada koko tietokannan yhdellä SQL-vastauksella.
Miten vastausta voi pienentää menettämättä tarvittavia tietoja?
Ensimmäiseksi kannattaa karsia tarpeettomat sarakkeet. Käytä SELECT * -lauseen sijaan vain kyseisessä toiminnossa tarvittavia kenttiä. Tämä pienentää vastausta etenkin silloin, kun taulukossa on pitkiä kuvauksia, JSON- tai BLOB-arvoja.
Toiseksi, lue rivejä osissa käyttämällä LIMIT- ja OFFSET-lausekkeita, kuten Cloudflare suosittelee. Käyttöliittymä voi esimerkiksi hakea seuraavan sivun vierityksen edetessä, ja eräajona toimiva tehtävä voi käsitellä osat erikseen. Lisää vakaa järjestys, esimerkiksi yksilöllisen tunnisteen mukaan: ilman sitä sivujen rajat voivat siirtyä, jos data muuttuu kyselyiden välillä.
Pitkissä vienneissä kannattaa myös tallentaa viimeksi käsitellyn tietueen tarkistuspiste. Näin tehtävää voi jatkaa häiriön jälkeen ilman koko aineiston uudelleenkäsittelyä. Sopiva toteutustapa riippuu sovelluksesta; keskeistä on rajata jokaisen vastauksen koko eikä luottaa yhteen kyselyyn, joka palauttaa koko aineiston kerralla.
Mitä sovelluksessa kannattaa tarkistaa?
Aloita kyselyistä, jotka palauttavat suuria listoja: raporttien vientitoiminnot, hallintanäkymät, taustatehtävät ja API-reitit, jotka palauttavat rivitaulukoita. Tallenna tilapäisesti sarjallistetun vastauksen koko tai valittujen kenttien määrä ja koot. Tarkista sen jälkeen suurin odotettu tietomäärä äläkä tyydy tavallisiin, pieniin testiaineistoihin.
Jos sovellus alkaa palauttaa virheen muutoksen jälkeen, D1-dokumentaatio liittää sen nimenomaan yli 50 Mt:n tulokseen ja neuvoo valitsemaan tarvittavat sarakkeet tai jakamaan tuloksen sivuihin. Näin vastauskoon ongelman voi erottaa suoritusajan, muistin tai tietokannan käytettävyyden rajoitteista, joilla on eri virheet ja syyt.
Yhteenveto tiimille on yksinkertainen: tavallisia lyhyitä hakuja ei todennäköisesti tarvitse muuttaa, mutta suuret lukutoiminnot kannattaa siirtää osissa käsiteltäviksi. Rajoitus ei itsessään estä suuremman tietokannan tallentamista eikä sulje pois vientiä REST API:n kautta; se edellyttää, että kyselyt suunnitellaan niin, ettei yksittäinen vastaus ylitä 50 Mt:ta.
