Mantén tus apps de Workers gratuitas con vida: indexa D1 y recorta el AI SDK

Los fallos a medianoche son fallos de presupuesto

Una app de Workers gratuita puede parecer bien durante el fin de semana y fallar después de medianoche. El límite cuenta las filas escaneadas por el motor de consultas, no las peticiones ni las filas que la aplicación realmente utiliza. Las consultas D1 en cuentas Cloudflare Workers Free fallan el 1 de septiembre de 2026 cuando la cuenta supera el límite diario de lecturas o escrituras de filas. Después de que una cuenta D1 del plan gratuito supere un límite diario, las peticiones realizadas con la Workers Binding API o la REST API fallan hasta que la cuota se restablece a medianoche UTC. El plan gratuito ofrece 5 millones de filas leídas por día, 100,000 filas escritas por día y 5 GB de almacenamiento.

La app puede seguir sintiéndose rápida. Una función pequeña puede ejecutar unas pocas consultas por página, y el tráfico del fin de semana puede parecer inofensivo. Si una página dispara una búsqueda lenta, la app puede agotar la cuota diaria antes de que el usuario note nada.

Esperar un tráfico más ligero no salvará la app. Audita el presupuesto de filas antes de que termine el fin de semana. Para un proyecto secundario, eso es una revisión breve de las consultas a la base de datos y la salida de compilación.

Las filas escaneadas son el contador real

Una consulta que devuelve una fila puede escanear muchas. Empieza por la lista de consultas, no por el panel. El checklist de abajo es una auditoría de filas, y cada punto es lo suficientemente pequeño como para terminarlo antes del próximo incidente.

Empieza con las consultas que tu app realmente ejecuta. Una app de fin de semana suele tener una lista corta: obtener un usuario, cargar elementos recientes, contar algo, actualizar un estado. Anótalas junto con la tabla que tocan y la condición que usan. La lista es un registro de dónde mira la app en la base de datos.

Luego busca las consultas que escanean la tabla completa. Un filtro en una columna sin índice puede obligar al motor a revisar cada fila, incluso cuando solo unas pocas coinciden. El mismo problema aparece en uniones y ordenamientos que la base de datos no puede optimizar. Si una consulta pide un subconjunto de filas y la tabla carece de un índice para esa búsqueda, el motor puede escanear muchas filas.

La solución más barata suele ser un pequeño cambio de esquema. Cambia cómo el motor encuentra las filas sin alterar la función. Si la app tiene unas pocas tablas muy consultadas, este cambio puede convertir una búsqueda lenta en una rápida.

• Lista todas las consultas a la base de datos y anota la tabla, el filtro y el ordenamiento.
• Marca las consultas que escanean tablas completas.
• Añade índices a las columnas que usan tus filtros y uniones para reducir las lecturas de filas.
• Verifica el número de filas escaneadas tras el cambio, no el número devuelto.
• Elige entre indexar o pagar cuando los escaneos sigan altos tras las correcciones obvias: añade índices o actualiza a un plan Workers Paid.
• Comprueba el bundle del AI SDK frente a 64 MiB descomprimidos.

Los primeros puntos encuentran el problema. Los posteriores deciden si el problema es corregible o facturable. Si la app está cerca del límite, haz esta revisión antes del siguiente despliegue.

El bundle tiene su propio techo

El techo del bundle es independiente del contador de filas. Una dependencia grande puede consumir tamaño descomprimido antes de que se ejecute una sola consulta. Mantén el AI SDK completo y el bundle lo suficientemente pequeño para desplegar. Si la compilación pasa, la app puede seguir funcionando durante el fin de semana.

Los límites de filas y los límites de bundle fallan de formas distintas. Uno aparece cuando el contador se llena. El otro aparece en el momento del despliegue, antes de que la app pueda arrancar. La comprobación del bundle parece una tarea tediosa, pero es la que puede detener una publicación.

No dependas de la compresión para ocultar el problema. Vigila el tamaño descomprimido tras cada actualización de dependencias. Si un paquete es la parte más pesada, mantenlo en un solo lugar y recorta lo que puedas.

Cuando el bundle está cerca del límite, la solución suele ser aburrida. Elimina una dependencia sin usar, reduce un recurso enorme o saca una utilidad pesada de la ruta principal. Apunta a un bundle que se despliegue, para que las correcciones de filas lleguen de verdad a los usuarios.