Лимиты Cloudflare D1 Free: когда база перестаёт отвечать

С 1 сентября 2026 года лимиты Cloudflare D1 Free напрямую влияют на доступность продакшена. Если за день аккаунт исчерпает одну из квот — 5 миллионов прочитанных строк или 100 000 записанных, — запросы к D1 могут прекратиться до полуночи по UTC.

Лимиты Cloudflare D1 не изменились — изменился сценарий отказа

Бесплатные квоты существовали и раньше. Изменилось то, что происходит при их исчерпании.

На Workers Free превышение любой из суточных квот теперь заставляет D1 отклонять запросы и через Workers Binding API, и через REST API. В документации Cloudflare для лимитов чтения и записи приведены разные сообщения об ошибке; там же сказано, что запросы возобновятся после сброса квоты в 00:00 UTC. Сохранённые данные останутся в целости, но приложение всё равно может потерять возможность читать или изменять их.

В этом и состоит главное отличие. Обычный показатель потребления превратился в жёсткую границу доступности.

Когда суточный лимит достигнут, Cloudflare отправляет письмо. Оно объяснит причину сбоя, но придёт уже после того, как база данных станет недоступна. Продакшен-команде нужны заранее заданный бюджет и раннее оповещение, а не только объяснение постфактум. В журнале изменений D1 от 1 сентября точно описаны поведение при отказе и текст ошибки.

Workers Paid эта суточная остановка не затрагивает. Прототипу, который уверенно укладывается в обе квоты, необязательно переходить на другой тариф прямо сегодня. Но продукт в продакшене, зависящий от D1, теперь должен относиться к Free как к любому другому ресурсу с точкой отключения.

Считать нужно просканированные строки

Квота на чтение — это не 5 миллионов вызовов API и не 5 миллионов записей в результате. Это 5 миллионов просканированных строк при выполнении запросов.

Допустим, фильтр возвращает одного клиента, но подходящего индекса нет. Чтобы найти запись, D1 может просканировать таблицу из 5 000 строк. Выполните такой запрос 1 000 раз — и все 5 миллионов строк суточной квоты на чтение израсходованы. Результат был крошечным, а скрытая за ним работа — нет.

С записью всё прямолинейнее. Для INSERT, UPDATE и DELETE учитывается число изменённых строк. Вставка 10 строк считается как 10 записанных строк. Операции со схемой, например CREATE, ALTER и DROP, тоже могут расходовать и чтения, и записи.

Размер строки на этот счётчик не влияет. Строка размером 1 КБ и строка размером 100 КБ считаются одинаково — как одна строка. Число чтений определяет именно форма запроса.

Индекс позволяет D1 сразу перейти к нужным записям вместо полного просмотра таблицы. Обычно небольшое увеличение числа операций записи даёт гораздо более заметное сокращение чтений. При записи в столбец, включённый в индекс, D1 записывает строку таблицы и как минимум одну строку индекса. Поэтому индексировать следует столбцы, которые часто используются в фильтрах и соединениях, а не всё подряд.

В руководстве Cloudflare по индексам предложена простая проверка. Добавьте перед ресурсоёмким запросом EXPLAIN QUERY PLAN. Если в плане показано SCAN, база читает таблицу; если SEARCH ... USING INDEX — использует индекс. После добавления индекса выполните PRAGMA optimize, чтобы планировщик запросов получил актуальную статистику.

Как изменилась экономика проекта

Workers Free по-прежнему стоит $0. Изменился риск: максимальный счёт за базу данных всё так же равен нулю, зато сама база теперь может до конца суток по UTC перестать обслуживать приложение.

Workers Paid стоит от $5 за аккаунт в месяц. Вместо жёсткой суточной остановки тариф предлагает включённый месячный объём и оплату перерасхода.

Разница между Free и Paid больше, чем кажется на первый взгляд. За тридцать дней на пределе бесплатной квоты чтения наберётся 150 миллионов строк — всего 0.6% от 25 миллиардов чтений, включённых в Paid. За те же тридцать дней на пределе квоты записи получится 3 миллиона строк, или 6% от включённых 50 миллионов.

Поэтому для многих небольших приложений первое решение о переходе на платный тариф связано не с перерасходом. Это решение заплатить $5 за доступность. У запросов Workers, процессорного времени, хранилища D1 сверх 5 ГБ и других продуктов Cloudflare остаются собственные счётчики, так что $5 — лишь нижняя граница, а не обещание, что весь аккаунт обойдётся ровно в $5. В подробном разборе цен Cloudflare показано, как разделяются тариф аккаунта и отдельные продукты.

У D1 нет платы за передачу данных или пропускную способность. Это не смягчает последствия отказа на Free, а лишь исключает исходящий трафик из расчётов при выборе тарифа.

Четыре команды — четыре практических решения

Основатель в одиночку с работающим SaaS

Если авторизация, статус оплаты или клиентская панель читают данные из D1, тариф Free теперь создаёт риск простоя продакшена. Сначала найдите самый загруженный обычный день, затем устраните полные сканирования. Если приложение всё равно приближается к лимиту, минимальные $5 обойдутся дешевле, чем готовность к неизвестному числу часов без доступа к базе.

Результат — не абстрактное увеличение ёмкости базы. Полночь по UTC просто исчезнет из плана восстановления после сбоя.

Агентство с несколькими базами в одном аккаунте

В формулировке Cloudflare лимит действует на уровне аккаунта. Поэтому агентству нужно учесть все базы D1 в аккаунте Cloudflare, а не проверить один клиентский проект и объявить весь аккаунт безопасным.

По метрикам отдельных баз найдите самый прожорливый проект, затем сложите показатели и только после этого задайте бюджет аккаунта. Так у операционной команды появится общий контролируемый показатель. Неэффективное сканирование в одном проекте не должно неожиданно отключать другой проект того же аккаунта.

Бэкенд-инженер, который ищет дорогие чтения

Нужно определить проблемные формы запросов, а не удалять данные наугад. D1 возвращает rows_read и rows_written в объекте meta каждого запроса. Эти значения показывают точную стоимость одного выполнения.

Cloudflare также предоставляет анализ запросов через Wrangler и GraphQL Analytics API. Отсортируйте запросы по числу чтений, найдите повторяющиеся сканирования, изучите план, добавьте подходящий узкий индекс и снова проведите замер. Результат — меньший расход квоты и, как правило, меньшая задержка после одного и того же изменения.

Руководитель эксплуатации, отвечающий за импорт или синхронизацию

Массовая синхронизация может израсходовать 100 000 записей ещё до того, как пользовательский трафик успеет обратиться к базе. Несрочную задачу стоит распределить между несколькими окнами сброса квоты либо до продакшен-импорта перевести аккаунт на Paid.

Не рассчитывайте на очистку после исчерпания квоты записи. DELETE сам является операцией записи, поэтому та же исчерпанная квота может блокировать запрос очистки до сброса. Практический результат — доступность рабочих операций записи во время пакетной обработки.

Задайте бюджет лимитов до первого оповещения

Для начала подойдёт следующее правило. Это внутренняя рекомендация для эксплуатации, а не требование Cloudflare: ограничить продакшен 80% от опубликованной квоты Free. Рабочий суточный потолок тогда составит 4 миллиона чтений и 80 000 записей, а резерв на всплески и задержку метрик — 1 миллион чтений и 20 000 записей.

1. 1

   Измерьте реальную суточную нагрузку

   Откройте Cloudflare, перейдите в D1, выберите каждую базу данных и откройте Metrics. По умолчанию отображаются последние 24 часа. Выберите достаточно длинный период, чтобы увидеть обычные будни, запуски, импорты и скачки трафика. D1 хранит эти метрики 31 день.

2. 2

   Найдите запрос, который расходует строки

   При тестировании важных сценариев используйте значения meta.rows_read и meta.rows_written для каждого запроса. С помощью анализа запросов составьте рейтинг часто выполняемых или ресурсоёмких выражений. Запустите EXPLAIN QUERY PLAN для худшего запроса чтения и устраните полное сканирование, прежде чем считать переход на другой тариф единственным решением.

3. 3

   Настройте оповещение до жёсткого лимита

   Настройте регулярную проверку аккаунта через GraphQL Analytics API, который читает те же наборы данных, что и панель управления. Оповещайте ответственного при 4 миллионах чтений или 80 000 записей. Письмо Cloudflare после полного исчерпания лимита по-прежнему пригодится как подтверждение инцидента, но не должно быть первым сигналом о проблеме в продакшене.

4. 4

   Заранее определите поведение при отказе

   Решите, что вернёт Worker, если D1 выдаст ошибку лимита. Кешированный ответ на чтение может оставаться полезным, если для него не выполняется ещё один запрос к D1. Для записи потребуется понятный ответ о недоступности либо отдельно спроектированная очередь. Не повторяйте запросы по кругу: квота не восстановится до полуночи по UTC или перехода на другой тариф.

В документации по метрикам D1 поля GraphQL называются rowsRead и rowsWritten; там же подтверждается, что панель управления использует те же аналитические данные. Небольшая команда получает ручной способ контроля уже сегодня и возможность автоматизации, когда база станет настолько важной, что сбои потребуют немедленного вызова ответственного.

Где у этого решения остаются ограничения

Индекс не даётся бесплатно. Он занимает место и добавляет операции записи при изменении индексированных значений. Добавляйте индексы, которые устраняют дорогие сканирования, а затем измеряйте новый баланс. Если аккаунт уже близок к лимиту в 100 000 записей, бездумная индексация может ухудшить ситуацию.

Paid тоже не безлимитен. В тариф включены 25 миллиардов чтений и 50 миллионов записей в месяц, после чего перерасход оплачивается по опубликованным ставкам. Переход на Paid снимает суточную остановку Free — обычно в течение нескольких минут, — но не отменяет необходимости отслеживать неэффективные запросы и прогнозировать остальную часть счёта Workers. Актуальную таблицу цифр стоит сохранить в регламенте: она находится на странице цен D1.

Есть нюанс в истории источников. В примечании к выпуску D1 за январь 2025 года говорилось, что применение лимитов начнётся 10 февраля 2025 года. Более новый журнал изменений, посвящённый именно этому событию, называет датой начала 1 сентября 2026 года. Здесь за основу взята новая страница, поскольку она прямо описывает текущий запуск. Поэтому в старом результате поиска может встречаться другая дата.

Наконец, фраза «сохранённые данные не затронуты» означает меньше, чем «с продуктом всё в порядке». Данные могут оставаться в безопасности, пока каждый маршрут, которому они нужны, возвращает ошибку. Для бизнеса важна именно доступность.

Что сделать в понедельник

Действуйте уже на этой неделе, если клиентское приложение работает на Workers Free, а D1 участвует в обработке запросов. Сначала проведите замеры, устраните очевидные полные сканирования, настройте оповещения на 4 миллионах чтений и 80 000 записей и заранее согласуйте переход на Paid за $5.

Можно подождать, если это одноразовый прототип, история за 31 день остаётся значительно ниже рабочего бюджета, а суточный отказ запросов не затронет клиентов или выручку. Но оповещение всё равно нужно сохранить: на расчёт чтений влияют и трафик, и размер таблиц.

Эта конкретная суточная остановка вас не касается, если аккаунт уже работает на Workers Paid или приложение не обращается к D1.

План на понедельник прост: откройте вкладку D1 Metrics для каждой базы, запишите максимальное суточное число чтений и записей по аккаунту, найдите запрос с самым большим сканированием и назначьте человека, уполномоченного сменить тариф. Если после исправления запроса обычный пик всё ещё превышает 4 миллиона чтений или 80 000 записей, в тот же день переведите аккаунт на Workers Paid.

Если следующий сдвиг на платформе тоже нужен в виде готового эксплуатационного решения, подпишитесь на рассылку.