Michael JohnsonЗапит до Cloudflare D1, який повертає результат розміром понад 50 МБ, із 4 листопада 2026 року завершується помилкою. Для розробника важливо розуміти межі цієї зміни: йдеться про розмір результату окремого запиту, а не про максимальний розмір бази. Імпорт і експорт через REST API під цей ліміт не підпадають, тож саме спосіб читання даних визначає, чи доведеться змінювати робочий процес.
Що саме обмежено?
Cloudflare описала цю зміну в дописі від 30 жовтня: запит, результат якого перевищує 50 МБ, повертає помилку D1 query result exceeded the maximum response size limit of 50 MB. Застосовувати ліміт почали 4 листопада 2026 року. У документації D1 його також зазначено як обмеження розміру результату запиту; водночас база може зберігати до 10 ГБ на платному плані або 500 МБ на безплатному.
Це різні рівні: сховище визначає обсяг даних у базі, а ліміт результату — скільки даних може повернути один запит. Тому база може містити значно більше ніж 50 МБ даних і залишатися доступною для читання частинами. Водночас навіть запит до невеликої бази може перевищити ліміт, якщо він вибирає багато широких рядків або великі текстові й двійкові поля.
У оголошенні Cloudflare про ліміт компанія зазначає, що поріг охоплює 99,999-й процентиль запитів D1. Це оцінка розподілу запитів, наведена постачальником; для перевірки застосунку важливіше виміряти конкретні відповіді й виявити запити, які повертають великі масиви даних.
Чому вивантаження через REST API — окремий випадок?
Зазвичай застосунок отримує результат виконання SQL і передає його коду, що викликав запит. Імпорт та експорт бази через REST API — інші операції: Cloudflare окремо зазначає, що на них новий поріг не поширюється і вони й надалі працюють, як раніше. Отже, помилка під час великої вибірки не означає, що з бази неможливо експортувати великий обсяг даних.
На практиці ця відмінність допомагає обрати правильний шлях. Якщо застосунку потрібні всі записи для відображення, обробки чи створення звіту, розбийте читання на порції. Якщо мета — перенести або вивантажити дані, перевірте сценарій експорту через REST API, а не намагайтеся отримати всю базу одним SQL-відгуком.
Як зменшити відповідь, не втративши потрібних даних?
Перший крок — прибрати зайві стовпці. Замість SELECT * вкажіть лише поля, потрібні для поточної операції. Це зменшує обсяг відповіді, особливо якщо таблиця містить довгі описи, JSON або значення BLOB.
Другий крок — читати рядки частинами за допомогою LIMIT і OFFSET, як рекомендує Cloudflare. Наприклад, інтерфейс може завантажувати наступну сторінку під час прокручування, а пакетне завдання — обробляти порції окремо. Додайте стабільне сортування, наприклад за унікальним ідентифікатором: без нього межі сторінок можуть змінюватися, якщо дані оновлюються між запитами.
Для тривалого вивантаження також варто зберігати контрольну точку останнього обробленого запису. Тоді завдання можна продовжити після збою, не обробляючи весь набір повторно. Конкретна схема залежить від застосунку; головний принцип — обмежувати розмір кожної відповіді, а не покладатися на один запит, що повертає весь набір цілком.
Що перевірити в застосунку
Почніть із запитів, які повертають великі списки: вивантажень для звітів, адміністративних екранів, фонових завдань і маршрутів API, що повертають масиви рядків. Тимчасово зафіксуйте обсяг серіалізованої відповіді або кількість і розміри вибраних полів. Потім перевірте максимальний очікуваний обсяг, а не лише звичайний невеликий набір тестових даних.
Якщо після зміни застосунок отримує помилку, документація D1 пов’язує її саме з результатом понад 50 МБ і радить вибирати потрібні стовпці або розбивати результат на сторінки. Це дає змогу відрізнити проблему з розміром відповіді від обмежень часу виконання, пам’яті чи доступності бази: вони мають інші помилки й причини.
Висновок для команди простий: звичайні короткі вибірки, імовірно, не потребуватимуть змін, а великі запити на читання варто перевести на порційну обробку. Сам ліміт не заважає зберігати більшу базу й не блокує експорт через REST API; він вимагає проєктувати запити так, щоб одна відповідь залишалася в межах 50 МБ.
