Vercel убрал лимиты на количество Blob stores

Что изменилось и зачем это важно

Vercel отказывается от прежних ограничений на число Blob stores: больше нет лимитов 100 для Hobby, 500 для Pro и 1000 для Enterprise. Теперь команды могут создавать любое количество хранилищ объектов по своему усмотрению.

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

Когда и как имеет смысл разносить данные по отдельным stores

Отдельный store для production, staging и preview упрощает разграничение данных и выдачу отдельных учётных данных для каждой среды. Это снижает риск случайного доступа среды разработки к production-данным и упрощает процессы CI/CD.

В мультиарендных приложениях отдельный store на клиента позволяет экспресс-экспорт или полное удаление данных одного арендатора в один вызов. Такое разделение сокращает количество дополнительных шагов при удовлетворении запросов на удаление данных или при миграции клиента.

Превью-ветки и временные миграции — ещё один сценарий: можно поднять store на время теста или миграции и удалить его по завершении. Это удобно для изолированных экспериментов или для поэтапного переноса данных.

Биллинг, наблюдаемость и практические ограничения расходов

Создание store теперь учитывается в разделе Blob Advanced Operations на странице использования и виджетах Observability. Это значит, что создание самого хранилища — это операция, которая попадает в отчётность и может влиять на счёт.

На платном тарифе Pro создание и операции blob-advanced тарифицируются по ставке $5.00 за миллион операций. Для Hobby создание store входит в ежемесячную квоту в 2 000 бесплатных операций. Удаление store остаётся бесплатным.

Хранение данных, операции put()/copy()/list() и передача данных по-прежнему тарифицируются по факту использования. Разделение одних и тех же данных между несколькими stores не меняет совокупной суммы за объём хранилища, операции и передачу — вы платите за то, что используете, независимо от того, как устроена структура stores.

Наблюдаемость и учёт

Создания stores отображаются в интерфейсе использования под Blob Advanced Operations и в Observability dashboard. Это даёт доступ к метрикам и позволяет отслеживать расходы и активность по каждому создаваемому store отдельно.

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

Ограничения и предостережения

Хотя количество stores теперь неограниченно, это не освобождает от оплаты за операции, хранение и передачу данных. Разделение одного набора данных по множеству stores не уменьшит, а иногда может увеличить число операций, если данные копируются или синхронизируются между ними.

Создание большого количества временных stores для коротких экспериментов требует контроля: хоть удаление бесплатное, создание и операции по ним учитываются в квотах и счётах. На Hobby это может быстро «съесть» бесплатные 2 000 операций в месяц.

Изменение видимости операций в Observability удобно, но не заменяет политики управления жизненным циклом данных. Разработчикам придётся выстроить внутренние правила: кто и когда может создавать store, как очищать временные stores и как объединять логику доступа.

Вывод для инженера и команды

Снятие лимитов освобождает архитектурные решения: можно оперировать отделёнными stores как явными границами данных. Это облегчает реализацию изолированных окружений, мультиарендности и временных веток для тестирования.

При планировании стоит учитывать влияние на бюджет: контролируйте операции и строите правила удаления временных stores, чтобы не перерасходовать квоты или бюджет на операции. Следите за отображением созданий в разделе Blob Advanced Operations и используйте Observability для выявления лишней активности.