Michael JohnsonDesde el 4 de noviembre de 2026, una consulta a Cloudflare D1 que devuelve un resultado de más de 50 MB falla. Para los desarrolladores, es importante delimitar el alcance de este cambio: se refiere al tamaño del resultado de una consulta individual, no al tamaño máximo de la base de datos. Las importaciones y exportaciones mediante la API REST no están sujetas a este límite, por lo que la forma de leer los datos determina si hay que cambiar el flujo de trabajo.
¿Qué se limita exactamente?
Cloudflare describió el cambio en una publicación del 30 de octubre: una consulta cuyo resultado supera los 50 MB devuelve el error D1 query result exceeded the maximum response size limit of 50 MB. La fecha de entrada en vigor es el 4 de noviembre de 2026. La documentación de D1 también indica que el límite se aplica al tamaño del resultado de la consulta; la base de datos, por su parte, puede almacenar hasta 10 GB en el plan de pago o 500 MB en el gratuito.
Se trata de niveles distintos: el almacenamiento determina la cantidad de datos que caben en la base de datos, mientras que el límite de resultados establece cuántos datos puede devolver una sola consulta. Por eso, una base de datos puede contener muchos más de 50 MB y seguir disponible para lecturas por partes. Aun así, una consulta a una base de datos pequeña puede superar el límite si selecciona muchas filas con numerosas columnas o campos grandes de texto o binarios.
En su anuncio del límite, Cloudflare indica que el umbral cubre el percentil 99,999 de las consultas de D1. Es una estimación de la distribución de consultas proporcionada por el proveedor; para comprobarlo en una aplicación, es más importante medir las respuestas concretas e identificar las consultas que devuelven grandes conjuntos de datos.
¿Por qué la exportación mediante la API REST es un caso distinto?
Una consulta de la aplicación suele obtener el resultado de ejecutar SQL y entregarlo al código que la invoca. La importación y exportación de bases de datos mediante la API REST son operaciones diferentes: Cloudflare indica por separado que no están sujetas al nuevo umbral y que siguen funcionando como antes. Por tanto, un error al realizar una consulta grande no significa que sea imposible exportar un gran volumen de datos de la base de datos.
En la práctica, esta diferencia ayuda a elegir la vía adecuada. Si la aplicación necesita todos los registros para mostrarlos, procesarlos o generar un informe, divide la lectura en lotes. Si el objetivo es transferir o exportar datos, utiliza el flujo de exportación mediante la API REST en lugar de intentar obtener toda la base de datos con una sola respuesta SQL.
¿Cómo reducir la respuesta sin perder los datos necesarios?
El primer paso es eliminar las columnas innecesarias. En lugar de SELECT *, indica solo los campos que necesita la operación actual. Así se reduce el tamaño de la respuesta, sobre todo si la tabla contiene descripciones largas, valores JSON o datos BLOB.
El segundo paso es leer las filas por partes con LIMIT y OFFSET, como recomienda Cloudflare. Por ejemplo, una interfaz puede cargar la página siguiente a medida que se desplaza el usuario, y una tarea por lotes puede procesar cada bloque por separado. Añade un orden estable, por ejemplo, por un identificador único: sin él, los límites de las páginas pueden cambiar si los datos se modifican entre consultas.
En las exportaciones largas, también conviene guardar un punto de control con el último registro procesado. Así, la tarea puede reanudarse tras un fallo sin volver a procesar todo el conjunto. El esquema concreto depende de la aplicación; el principio clave es limitar el tamaño de cada respuesta, en lugar de depender de una única consulta que devuelva todo el conjunto de una vez.
Qué revisar en la aplicación
Empieza por las consultas que devuelven listas grandes: exportaciones para informes, pantallas administrativas, tareas en segundo plano y rutas de API que envían matrices de filas. Registra temporalmente el tamaño de la respuesta serializada o el número y el tamaño de los campos seleccionados. Después, comprueba el volumen máximo esperado, no solo el de los pequeños conjuntos de datos habituales en las pruebas.
Si la aplicación recibe un error tras el cambio, la documentación de D1 lo atribuye específicamente a resultados de más de 50 MB y recomienda seleccionar las columnas necesarias o paginar el resultado. Esto permite distinguir un problema con el tamaño de la respuesta de las limitaciones de tiempo de ejecución, memoria o disponibilidad de la base de datos, que tienen causas y errores distintos.
La conclusión para el equipo es sencilla: probablemente no haya que modificar las consultas breves habituales, pero sí conviene procesar por partes las lecturas grandes. El límite no impide almacenar una base de datos de mayor tamaño ni bloquea las exportaciones mediante la API REST; exige diseñar las consultas para que cada respuesta se mantenga por debajo de 50 MB.
