Cloudflare D1: cuándo se detienen las consultas del plan gratuito
Los límites gratuitos de Cloudflare D1 ya pueden detener consultas. Entiende qué cuenta como lectura, cuándo migrar a Paid y cómo alertar antes del corte.
Desde el 1 de septiembre de 2026, usar Cloudflare D1 Free en producción implica tomar una decisión de disponibilidad. Cuando una cuenta consume 5 millones de lecturas de filas o 100,000 escrituras de filas en un día, las consultas de D1 pueden detenerse hasta la medianoche UTC.
Cloudflare D1 cambió su forma de fallar, no la cuota
Los límites gratuitos ya existían. Lo que cambió es qué ocurre cuando se alcanzan.
En Workers Free, superar cualquiera de las dos cuotas diarias ahora hace que D1 rechace las consultas tanto en la Workers Binding API como en la REST API. Cloudflare documenta mensajes distintos para los límites de lectura y escritura, e indica que las consultas se reanudan cuando la cuota se restablece a las 00:00 UTC. Los datos almacenados permanecen intactos, aunque la aplicación puede quedarse sin capacidad para leerlos o modificarlos.
Ahí está la clave: una cifra de consumo que antes era solo una referencia se convirtió en un límite estricto de disponibilidad.
Cloudflare envía un correo cuando se alcanza el límite diario. El mensaje explica la causa del incidente, pero llega cuando la base de datos ya no está disponible. Un equipo de producción necesita un presupuesto de uso y una alerta previa, no solo una explicación después del fallo. El registro de cambios de D1 del 1 de septiembre detalla el comportamiento exacto del fallo y los mensajes de error.
Workers Paid no se ve afectado por esta interrupción diaria. Un prototipo que se mantenga con holgura por debajo de ambas cuotas quizá no tenga que migrar hoy. En cambio, un producto activo que depende de D1 debe tratar Free como cualquier otro recurso con un punto de corte.
En Cloudflare D1 cuentan las filas examinadas
La cuota de lectura no equivale a 5 millones de llamadas a la API ni a 5 millones de registros devueltos. Equivale a 5 millones de filas examinadas por la base de datos al resolver las consultas.
Supongamos que un filtro devuelve un solo cliente, pero no dispone de un índice útil. D1 puede tener que recorrer una tabla de 5,000 filas para encontrar ese registro. Si la misma consulta se ejecuta 1,000 veces, habrá consumido los 5 millones de lecturas de filas del día. El resultado parecía pequeño; el trabajo necesario para obtenerlo no lo era.
Las escrituras son más directas. Un INSERT, UPDATE o DELETE cuenta las filas modificadas. Insertar 10 filas equivale a 10 filas escritas. Las operaciones de esquema como CREATE, ALTER y DROP también pueden consumir una combinación de lecturas y escrituras.
El tamaño de la fila no altera este contador. Una fila de 1 KB y otra de 100 KB cuentan como una fila cada una. Lo que determina el consumo de lecturas es la forma de la consulta.
Un índice permite que D1 salte directamente a los registros pertinentes, en lugar de recorrer toda la tabla. Por lo general, esto intercambia un pequeño aumento en las escrituras por una reducción mucho mayor en las lecturas. Al escribir en una columna cubierta por un índice, D1 actualiza la fila de la tabla y al menos una fila del índice. Por eso conviene indexar las columnas utilizadas en filtros y uniones frecuentes, no todas las columnas sin criterio.
La guía de índices de Cloudflare propone una comprobación sencilla. Anteponer EXPLAIN QUERY PLAN a la consulta costosa permite ver el plan: SCAN indica que se está recorriendo la tabla, mientras que SEARCH ... USING INDEX confirma el uso de un índice. Después de añadirlo, hay que ejecutar PRAGMA optimize para que el planificador disponga de estadísticas actuales.
La ecuación económica ya no es la misma
Workers Free sigue costando $0. Lo que cambió es el riesgo: la factura máxima de la base de datos continúa en cero, pero esta puede dejar de atender a la aplicación durante el resto del día UTC.
Workers Paid parte de $5 por cuenta al mes. En lugar de una interrupción diaria obligatoria, ofrece consumo mensual incluido y cobra el excedente.
El salto de Free a Paid es mayor de lo que parece. Treinta días en el límite de lectura de Free sumarían 150 millones de filas, apenas el 0.6% de los 25 mil millones de lecturas incluidas en Paid. Treinta días en el límite de escritura de Free sumarían 3 millones de filas, es decir, el 6% de los 50 millones de escrituras incluidas.
Por eso, para muchas aplicaciones pequeñas, la primera decisión de pago no tiene que ver con el consumo excedente. Es una decisión de disponibilidad de $5. Las solicitudes de Workers, la CPU, el almacenamiento de D1 por encima de 5 GB y los demás productos de Cloudflare mantienen sus propios contadores; esos $5 son el punto de partida, no una promesa de que toda la cuenta costará exactamente $5. El análisis más amplio de precios de Cloudflare explica dónde se separan los cargos de la cuenta y de cada producto.
D1 no cobra por transferencia de datos ni por throughput. Eso no reduce el impacto del fallo en Free; simplemente significa que el tráfico saliente no forma parte de las cifras necesarias para decidir.
Cuatro equipos y cuatro decisiones prácticas
Quien gestiona en solitario un SaaS activo
Si el inicio de sesión, el estado de facturación o el panel del cliente consultan D1, el plan Free ya introduce un riesgo de caída en producción. El primer paso es localizar el día normal con más actividad y corregir los recorridos completos de tablas. Si la aplicación aun así se acerca al límite, el mínimo de $5 resulta más barato que planificar en torno a una cantidad desconocida de horas sin acceso a la base de datos.
El beneficio no es una capacidad abstracta mayor. Es eliminar la medianoche UTC del plan de recuperación ante incidentes.
Una agencia con varias bases de datos en una cuenta
El límite se define a nivel de cuenta. Una agencia debe inventariar todas las bases de datos D1 de esa cuenta de Cloudflare, en vez de revisar la propiedad de un solo cliente y dar la cuenta por segura.
Las métricas de cada base de datos permiten detectar el proyecto que genera más carga. Después hay que sumar los totales antes de fijar el presupuesto de la cuenta. El resultado es una cifra compartida de la que el equipo de operaciones puede hacerse responsable. Un recorrido ineficiente en un proyecto no debería manifestarse como una interrupción inexplicable en otro proyecto de la misma cuenta.
Un ingeniero de backend que investiga lecturas costosas
El objetivo es identificar patrones de consulta, no borrar datos al azar. D1 devuelve rows_read y rows_written dentro del objeto meta de cada consulta. Esos valores muestran el costo exacto de una ejecución.
Cloudflare también ofrece información de consultas mediante Wrangler y la GraphQL Analytics API. Ordenar por lecturas permite encontrar los recorridos repetidos; después se inspecciona el plan, se añade el índice específico y se vuelve a medir. El resultado es un menor consumo de cuota y, por lo general, también una menor latencia gracias al mismo cambio.
Un responsable de operaciones que ejecuta importaciones o sincronizaciones
Una sincronización masiva puede consumir 100,000 escrituras antes de que el tráfico de clientes tenga oportunidad de usar la base de datos. Una tarea no urgente puede distribuirse entre varias ventanas de restablecimiento; otra opción es migrar la cuenta a Paid antes de una importación en producción.
No conviene dejar la limpieza para después de alcanzar el límite de escritura. DELETE también es una operación de escritura, por lo que la misma cuota agotada puede bloquear la consulta de limpieza hasta el restablecimiento. El beneficio es reservar las escrituras en vivo para los usuarios mientras se ejecuta el proceso por lotes.
Define el presupuesto de límites antes de recibir la alerta
Esta es una primera política viable. Se trata de una regla operativa, no de un requisito de Cloudflare: asignar a producción el 80% de la cuota Free publicada. Así, el techo operativo diario queda en 4 millones de lecturas y 80,000 escrituras, con una reserva de 1 millón de lecturas y 20,000 escrituras para picos y retrasos en la medición.
Mide el consumo de un día real
Abre Cloudflare, entra en D1, selecciona cada base de datos y abre Metrics. La vista predeterminada muestra las últimas 24 horas. Consulta suficiente historial para incluir días habituales entre semana, lanzamientos, importaciones y picos de tráfico. D1 conserva estas métricas durante 31 días.
Encuentra la consulta que consume las filas
Al probar las rutas importantes, revisa los valores
meta.rows_readymeta.rows_writtende cada consulta. Usa la información de consultas para ordenar las sentencias frecuentes o costosas. EjecutaEXPLAIN QUERY PLANsobre la peor consulta de lectura y corrige cualquier recorrido completo antes de asumir que cambiar de plan es la única solución.Activa una alerta antes del límite estricto
Programa una comprobación de la cuenta mediante la GraphQL Analytics API, que consulta los mismos conjuntos de datos que el panel. Avisa a la persona responsable al alcanzar 4 millones de lecturas u 80,000 escrituras. El correo de Cloudflare al llegar al límite total sigue siendo útil para confirmar el incidente, pero no debería ser la primera señal en producción.
Define ahora cómo responderá la aplicación al fallo
Decide qué debe devolver el Worker si D1 genera un error de límite. Una lectura almacenada en caché puede seguir sirviendo si no ejecuta otra consulta a D1. Una ruta de escritura necesita una respuesta clara de indisponibilidad o una cola diseñada por separado. No repitas los intentos en bucle frente a una cuota que no se recuperará hasta la medianoche UTC o hasta que se actualice el plan.
La documentación de métricas de D1 identifica rowsRead y rowsWritten como los campos de GraphQL y confirma que el panel utiliza los mismos datos analíticos. Así, un equipo pequeño dispone hoy de un método manual y puede automatizarlo cuando la base de datos sea lo bastante importante como para avisar a una persona de guardia.
Lo que esta solución no resuelve
Un índice no es gratuito. Ocupa almacenamiento y añade escrituras cuando cambian los valores indexados. Conviene incorporar solo los índices que eliminen recorridos costosos y medir después el nuevo equilibrio. Una cuenta que ya roza el límite de 100,000 escrituras puede empeorar la situación si indexa sin criterio.
Paid tampoco es ilimitado. Incluye 25 mil millones de lecturas y 50 millones de escrituras al mes; después factura el excedente según las tarifas publicadas. El cambio de plan elimina la interrupción diaria de Free, normalmente en cuestión de minutos, pero no evita la necesidad de vigilar consultas deficientes ni de prever el resto de la factura de Workers. La página actual de precios de D1 es la referencia de cifras que conviene conservar en el manual operativo.
Hay un matiz en el historial de fuentes. Una nota de lanzamiento de D1 de enero de 2025 anunciaba que la aplicación de los límites comenzaría el 10 de febrero de 2025. El registro de cambios más reciente y específico del evento señala el 1 de septiembre de 2026. Aquí se toma la página más reciente como referencia principal porque nombra directamente el despliegue actual. Esto explica que un resultado de búsqueda antiguo pueda mostrar otra fecha.
Por último, «los datos almacenados no se ven afectados» no significa que «el producto funciona con normalidad». Los datos pueden estar seguros mientras todas las rutas que dependen de ellos devuelven un error. La consecuencia para el negocio es la disponibilidad.
Qué hacer este lunes
Conviene actuar esta semana si una aplicación de cara al cliente funciona en Workers Free y D1 forma parte de la ruta de cada solicitud. Primero hay que medir, corregir los recorridos evidentes, configurar la alerta en 4 millones de lecturas y 80,000 escrituras y dejar preautorizada la migración a Paid por $5.
Se puede esperar si se trata de un prototipo desechable, el historial de 31 días se mantiene muy por debajo del presupuesto operativo y un día sin consultas no afectaría a clientes ni ingresos. Aun así, conviene conservar la alerta, porque tanto el tráfico como el tamaño de las tablas cambian el cálculo de lecturas.
Esta interrupción diaria concreta no afecta a las cuentas que ya están en Workers Paid ni a las aplicaciones que no consultan D1.
La acción del lunes es sencilla: abre la pestaña D1 Metrics de cada base de datos, anota el día de mayor consumo de lecturas y escrituras de la cuenta, identifica la consulta responsable del recorrido más grande y autoriza a una persona para actualizar el plan. Si un pico normal sigue superando 4 millones de lecturas u 80,000 escrituras después de corregir la consulta, migra la cuenta a Workers Paid ese mismo día.
Si quieres convertir el próximo cambio de plataforma en una decisión operativa, suscríbete al boletín.
2 sept 2026
Prefiera este sitio en Google
Marque omidsaffari.com como fuente preferida y Google lo destacará para usted en Top Stories, AI Overviews y AI Mode.
