Michael JohnsonZapytanie do Cloudflare D1, które zwraca wynik większy niż 50 MB, od 4 listopada 2026 roku kończy się błędem. Dla programistów ważne jest, czego dotyczy ta zmiana: rozmiaru wyniku pojedynczego zapytania, a nie maksymalnej wielkości bazy. Import i eksport przez REST API nie podlegają temu limitowi, więc to sposób odczytu danych decyduje o tym, czy trzeba zmienić dotychczasowy proces.
Co dokładnie podlega limitowi?
Cloudflare opisało zmianę we wpisie z 30 października: zapytanie, którego wynik przekracza 50 MB, zwraca błąd D1 query result exceeded the maximum response size limit of 50 MB. Limit zaczyna obowiązywać 4 listopada 2026 roku. Dokumentacja D1 również określa go jako ograniczenie rozmiaru wyniku zapytania; baza może przy tym przechowywać do 10 GB w płatnym planie lub 500 MB w bezpłatnym.
To dwa różne poziomy: limit przechowywania określa ilość danych w bazie, a limit wyniku — ilość danych zwracanych przez jedno zapytanie. Dlatego baza może zawierać znacznie więcej niż 50 MB danych i nadal być dostępna do odczytu partiami. Nawet zapytanie do niewielkiej bazy może jednak przekroczyć limit, jeśli pobiera wiele szerokich wierszy albo duże pola tekstowe i binarne.
W ogłoszeniu Cloudflare o limicie firma podaje, że próg obejmuje 99,999. percentyl zapytań D1. Jest to oszacowanie rozkładu zapytań przedstawione przez dostawcę; weryfikując własną aplikację, ważniejsze jest zmierzenie konkretnych odpowiedzi i wskazanie zapytań zwracających duże zbiory danych.
Dlaczego eksport przez REST API to odrębny przypadek?
Zapytanie aplikacji zwykle zwraca wynik wykonania SQL i przekazuje go kodowi wywołującemu. Import i eksport bazy przez REST API to inne operacje: Cloudflare wyraźnie zaznacza, że nie obejmuje ich nowy próg i nadal działają jak dotychczas. Błąd przy pobieraniu dużego zbioru nie oznacza więc, że nie można wyeksportować dużej ilości danych z bazy.
W praktyce to rozróżnienie pomaga wybrać właściwą ścieżkę. Jeśli aplikacja potrzebuje wszystkich rekordów do wyświetlenia, przetworzenia lub przygotowania raportu, podziel odczyt na partie. Jeśli celem jest przeniesienie albo wyeksportowanie danych, sprawdź eksport przez REST API zamiast próbować pobrać całą bazę w jednej odpowiedzi SQL.
Jak zmniejszyć odpowiedź, nie tracąc potrzebnych danych?
Pierwszym krokiem jest pominięcie zbędnych kolumn. Zamiast SELECT * wskaż tylko pola potrzebne w danej operacji. Ograniczy to rozmiar odpowiedzi, zwłaszcza jeśli tabela zawiera długie opisy, wartości JSON lub BLOB.
Drugim krokiem jest odczytywanie wierszy partiami za pomocą LIMIT i OFFSET, zgodnie z zaleceniem Cloudflare. Interfejs może na przykład pobierać kolejną stronę podczas przewijania, a zadanie wsadowe — przetwarzać osobne porcje. Dodaj stabilne sortowanie, na przykład według unikatowego identyfikatora: bez niego granice stron mogą się przesuwać, gdy dane zmieniają się między zapytaniami.
W przypadku długotrwałych eksportów warto też zapisywać punkt kontrolny wskazujący ostatni przetworzony rekord. Dzięki temu zadanie można wznowić po awarii bez ponownego przetwarzania całego zbioru. Konkretne rozwiązanie zależy od aplikacji; kluczowa zasada to ograniczanie rozmiaru każdej odpowiedzi, zamiast polegania na jednym zapytaniu zwracającym cały zbiór naraz.
Co sprawdzić w aplikacji
Zacznij od zapytań zwracających duże listy: eksportów na potrzeby raportów, ekranów administracyjnych, zadań działających w tle i tras API zwracających tablice wierszy. Tymczasowo zapisuj rozmiar serializowanej odpowiedzi albo liczbę i rozmiar pobieranych pól. Następnie sprawdź maksymalny przewidywany rozmiar, a nie tylko niewielki, typowy zestaw danych testowych.
Jeśli po wprowadzeniu zmiany aplikacja otrzymuje błąd, dokumentacja D1 wiąże go z wynikiem większym niż 50 MB i zaleca wybieranie potrzebnych kolumn lub stronicowanie wyników. Pozwala to odróżnić problem rozmiaru odpowiedzi od ograniczeń czasu wykonania, pamięci lub dostępności bazy — te mają inne komunikaty błędów i przyczyny.
Wniosek dla zespołu jest prosty: zwykłe, krótkie zapytania prawdopodobnie nie będą wymagały zmian, natomiast duże odczyty warto przestawić na przetwarzanie partiami. Sam limit nie przeszkadza w przechowywaniu większej bazy ani nie blokuje eksportu przez REST API; wymaga jedynie projektowania zapytań tak, by pojedyncza odpowiedź mieściła się w 50 MB.
