Vercel elimina límites de Blob stores en todos los planes

Vercel elimina los topes y mete la creación de stores en la factura por operaciones

Hasta hoy, Vercel Blob tenía un corsé poco documentado pero muy real: 100 stores en Hobby, 500 en Pro y 1.000 en Enterprise. Eran cifras que Vercel no destacaba en su tabla de precios, pero que aparecían cuando un founder con un SaaS multi-tenant o con docenas de entornos de preview intentaba provisionar el número 101 y la API respondía con un 403. A partir del 23 de septiembre de 2026 esos topes desaparecen en todos los planes: se pueden crear tantos Blob stores como el caso de uso exija, según el changelog publicado por Vercel.

El cambio no es solo cosmático. Vercel deja de cobrar la creación de un store como un «slot» y la pasa a la factura variable, alineándola con el resto de Advanced Operations (put(), copy(), list() y, desde ahora, el alta del propio store). El precio de esa operación queda en US$5,00 por millón en el plan Pro y se descuenta de las 2.000 operaciones gratuitas que Hobby regala cada mes. Borrar un store sigue siendo gratis, según la documentación de Vercel.

Qué cambia exactamente para un founder

El cambio toca una decisión de arquitectura que la mayoría de equipos pequeños estaba resolviendo mal: cómo aislar datos cuando un mismo backend sirve a muchos clientes o a muchos entornos. Hasta ahora, lo más habitual era meter todo en un único Blob store y separar por convención de pathnames (/cliente-123/uploads/...), un parche que funciona al principio y se rompe cuando llega un cliente enterprise que pide exportar «sus» archivos, o un regulator que te obliga a borrar datos verificables de un usuario en concreto.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La nueva política, en la práctica, habilita tres patrones que antes tenían fricción:

Separar producción, staging y preview con stores distintos y credenciales independientes, de modo que un error de código en preview no pueda borrar contenido real.
Un store por cliente en un SaaS multi-tenant, lo que permite exportar o eliminar los datos de un tenant con una sola llamada, requisito habitual en migraciones, RGPD y churn masivo.
Stores efímeros para preview branches o migraciones puntuales, que se crean al levantar el branch y se destruyen al cerrar el PR — exactamente el flujo que las ramas de preview de Vercel ya promueven.

Vercel lo deja escrito en su propia documentación: «Use separate stores to isolate projects, environments, customers, or public and private content».

Por qué importa: aislamiento multi-tenant a coste cero extra

La trampa de los planes anteriores era estructural. Como había límite, los founders racionalizaban el aislamiento: un store por entorno, sí, pero todo el contenido de clientes mezclado en el mismo, separados solo por prefijo. Eso convierte una exportación de datos en un job que recorre prefix por prefix, con riesgo de olvidarse uno y dejar restos de un tenant borrado en producción. Joey D’Antoni, en Redmond Magazine, lo describe como el trade-off clásico de los multi-tenant apps: o compras aislamiento fuerte (un entorno por cliente, caro) o te comes el riesgo de meter todo en una sola base (barato hasta que te multan).

Vercel acaba de mover la aguja hacia el extremo «más aislamiento, mismo coste», porque el precio total no cambia al partir los datos en más stores: el cobro sigue siendo por GB almacenado, operaciones y transferencia, no por número de stores. Literalmente dice Vercel: «Splitting the same data across more stores doesn’t change those costs.»

Eso es relevante porque en el modelo antiguo el coste de escalar aislamiento era doble: el límite duro del plan y la operación extra que ya contaban las creaciones de store contra el cupo de Advanced Operations. Con el nuevo modelo, el coste marginal de crear el store número 1.001 es el mismo que el del primero: una Advanced Operation. En Hobby, mientras no superes las 2.000 operaciones mensuales gratuitas, es gratis.

Cómo se traduce esto en la factura

Según la tabla de precios de Vercel Blob vigente en septiembre de 2026, el desglose para un proyecto Pro queda así:

Storage: US$0,023 por GB-mes (1 GB incluido en Hobby).
Simple Operations (lecturas en cache miss + head()): US$0,40 por millón.
Advanced Operations (put, copy, list y, ahora, creación de stores): US$5,00 por millón.
Data Transfer: US$0,05 por GB en egress.
Blob Data Transfer es, según Vercel, ~3× más eficiente que Fast Data Transfer para servir blobs.

El ejemplo oficial de la propia docu: 120.000 blobs subidos al mes, 50 GB de storage, 2,5 millones de descargas con 70% de cache hit, da un total de US$26,93 al mes. En ese ejemplo, las Advanced Operations (subidas + multipart + creación de stores) suman solo US$1,68 — un coste menor que la transferencia de datos, lo que confirma que el modelo está pensado para que crees stores sin mirar el contador.

Además, borrar un store no cuesta, lo que permite usar stores efímeros para preview branches, migraciones o experimentos de QA sin miedo a la factura del mes siguiente. También del() es gratis, y los multipart cuentan como varias operaciones (una de inicio, una por parte, una de cierre), así que planificar subidas grandes merece un cálculo aparte.

Qué significa esto para tu startup

Si estás en Hobby y arrastras el clásico límite de 100 stores que ya te apretaba, este cambio es una liberación: planifica la arquitectura multi-tenant que ibas a querer dentro de seis meses, no la que te cabe hoy. Como Hobby no cobra extra por encima del límite incluido (lo corta en seco, según la docu: «you will not pay for any additional usage»), vigila que tu consumo de Advanced Operations no supere las 2.000/mes o el servicio se pausa hasta el ciclo siguiente.

Dos acciones concretas que puedes implementar esta semana:

Audita tu uso actual de Vercel Blob y mapea qué clientes, entornos o features están compartiendo store. Si tienes SaaS B2B, pregúntate cuántos clientes están pidiendo «exportar mis datos» o «borrar todo lo mío» y si podrías responder a eso con un único delete store en lugar de un job de limpieza por prefixes.
Crea un store por entorno de preview y automatiza su ciclo de vida: provisionar al abrir el PR y destruir al cerrar. Con del gratis y la creación ya en operaciones, el coste marginal es despreciable y eliminas el riesgo de que un preview branch escriba contra producción.

Si estás en Pro, revisa el panel de Observability de Vercel Blob: las creaciones de store ya aparecen dentro de Blob Advanced Operations, mezcladas con put, copy y list. Esto te obliga a etiquetar bien los stores desde el día uno (nombre + tag de entorno o tenant) porque la factura ya no los separa como antes.

El contexto: Vercel en plena carrera por la nube de IA

El anuncio llega en un momento clave para Vercel. Según Wikipedia, en septiembre de 2025 la compañía cerró una Serie F de US$300 millones con valoración de US$9.300 millones, co-liderada por Accel y GIC, con el foco puesto en escalar lo que llaman la «AI cloud». En marzo de 2026 fichó a Mitchell Hashimoto, cofundador de HashiCorp y creador de Terraform, para su directorio. Y en abril de 2026 reconoció un incidente de seguridad originado en un proveedor externo (Context.ai) que expuso credenciales internas.

En ese contexto, eliminar fricciones operativas como los límites de Blob stores tiene doble lectura: por un lado, mejora la propuesta para los equipos que construyen SaaS sobre Vercel; por otro, reduce el «ticket de soporte» típico de founders que descubren el límite cuando ya están en producción. Para un founder hispano que evalúa dónde montar su infraestructura, la señal es que Vercel está apretando el modelo de precios hacia consumo puro, lo que facilita proyectar costes pero exige disciplina de observability.