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 МБ.
