# Límites de escala de Bubble: cuáles pesan de verdad > Bubble publica sus límites duros. Casi ninguno te va a alcanzar. Mira cuáles deciden si una operación sigue creciendo en la plataforma y cuáles son solo ruido. - Autor: Marlon Trettin - Publicado: 2026-08-21 · Actualizado: 2026-08-21 - Idioma: es - Canonical: https://yowpi.com/es/blog/limites-de-escala-de-bubble-cuales-pesan --- Bubble publica sus límites duros, y la mayoría nunca va a tocar tu aplicación. Los que deciden si una operación puede seguir creciendo son la búsqueda ordenada topada en 50.000 elementos, el campo de lista topado en 10.000 registros, el tiempo de espera de cinco minutos en los workflows y una cuenta que crece según cómo se construyó la aplicación. El resto es ruido. ## TL;DR - Bubble afirma con claridad que [no aplica rate limit](https://manual.bubble.io/help-guides/optimizing-an-application/hosting-and-scaling/scaling-with-bubble) a tu aplicación. La velocidad no empeora con el consumo, lo que descarta la suposición más común sobre llegar al techo. - Los [límites duros documentados](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling/hard-limits) que pesan en la práctica son de búsqueda ordenada, campo de lista y duración de workflow, no de volumen de base de datos. - El techo real suele ser comercial y no técnico: el costo de workload sigue cómo se construyó la aplicación, no lo que factura. - Llegar a un límite es señal de diseño antes que veredicto de plataforma. Algunos se arreglan dentro de Bubble, y averiguar cuáles sale más barato que migrar. ## ¿La aplicación en Bubble se vuelve más lenta al crecer? No, y conviene decirlo con claridad porque es la suposición con la que llega la mayoría de los equipos. La documentación de escalado de Bubble lo resuelve en una línea: ["We don't rate limit: Your app will run at the same pace no matter how much workload it consumes"](https://manual.bubble.io/help-guides/optimizing-an-application/hosting-and-scaling/scaling-with-bubble). Eso cambia la decisión. Si el rendimiento cayera con el volumen, el crecimiento por sí solo forzaría la migración en un plazo predecible. No cae. Lo que crece con el volumen es la cuenta, y una cuenta es otro tipo de problema: negociable, a veces con arreglo, y fácil de postergar un trimestre más. Así que la pregunta honesta no es "¿Bubble se va a poner lento?". Es "¿qué límites concretos están entre mi operación y donde necesita estar en un año?". ## ¿Qué límites duros se alcanzan de verdad? Cuatro, según nuestra experiencia, y se concentran en listas y trabajo largo, no en volumen bruto de datos. **La búsqueda ordenada topa en 50.000 elementos.** Bubble documenta que [una búsqueda con ordenamiento devuelve como máximo 50.000 elementos](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling/hard-limits). Es el primero que encuentra la mayoría, porque los reportes y las exportaciones son justamente donde se ordena un conjunto grande. Suele aparecer como un reporte que en silencio deja de estar completo, no como un error que alguien nota. **El campo de lista topa en 10.000 registros.** La misma página fija el límite de 10.000 registros para almacenamiento en lista. Este duele porque la lista es la forma más natural de modelar una relación dentro de un editor visual, y el arreglo es un cambio de modelo de datos, no de configuración. **Los workflows expiran a los 300 segundos.** Todo lo que corra más de [cinco minutos sufre un tiempo de espera](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling/hard-limits). Los procesos por lote, el cierre de mes y las importaciones grandes viven en ese borde, y se acercan más cada mes que el negocio crece. **Las páginas topan en 10.000 elementos, eventos y acciones sumados.** Este es generoso, y una aplicación que lo alcanza suele estar diciendo algo sobre cómo se construyó la página, no sobre la plataforma. Los límites que preocupan de antemano rara vez son los que llegan. Un campo de texto guarda 10 millones de caracteres, un registro guarda 20 MB, las subidas llegan a 5 GB y una aplicación define hasta 1.000 tipos de dato propios. No son las restricciones de una operación en crecimiento. ## ¿Y los límites que no son técnicos? Son los que deciden la mayoría de las migraciones. Bubble cobra el trabajo de servidor en unidades de workload, y su [FAQ de precios](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) fija el excedente base en USD 0,30 por cada 1.000 unidades para quien no tiene suscripción de tier. El número en sí no es el problema. El problema es a qué está atado: el consumo sigue cómo se construyó la aplicación, así que dos aplicaciones con tráfico idéntico pueden facturar muy distinto porque alguien eligió una búsqueda en lugar de una consulta directa, o llevó al servidor un cálculo que no necesitaba estar ahí. Hay un borde más duro en la misma página. Con el overage desactivado, la aplicación que alcanza el límite queda fuera de línea y vuelve al inicio del siguiente período de facturación. Eso convierte la disponibilidad en una configuración de cobro, y es el comportamiento documentado que más veces cierra la discusión internamente. ## ¿Llegar a un límite es razón para irse? Normalmente no por sí solo. Un límite alcanzado es señal de diseño antes que veredicto de plataforma, y el orden de la investigación ahorra dinero de verdad. Pregunta primero si el límite es estructural o accidental. Una búsqueda ordenada que topa en 50.000 en un reporte mensual suele ser una consulta que debió filtrar antes de ordenar. Un campo de lista en 10.000 registros suele ser una relación que se modeló como lista porque las listas eran más fáciles. Ambos se arreglan dentro de Bubble, y arreglarlos compra tiempo. Pregunta después cuánto cuesta el arreglo contra cuánto cuesta quedarse. En la [plataforma de Colo Saúde](/es/cases/colo-saude) el primer movimiento fue deliberadamente quedarse: la aplicación se estabilizó en Bubble y su consumo se redujo en 60%, y solo entonces empezó la reconstrucción. Esa secuencia existe porque el margen de tiempo decide si la migración es tranquila o apurada. Pregunta por último si los límites que estás alcanzando seguirán ahí con tres veces el volumen. Algunos techos retroceden cuando arreglas la consulta. El tiempo de espera de cinco minutos no retrocede, llega más rápido. Cuando las respuestas apuntan al mismo lado, el marco de decisión está en [migrar de Bubble a código propio](/es/blog/migrar-de-bubble-a-codigo-propio). ## Preguntas frecuentes **¿Mi aplicación en Bubble se va a poner más lenta al crecer?** Bubble afirma que no aplica rate limit y que la aplicación corre al mismo ritmo sin importar cuánto workload consuma. Lo que crece con el uso es la cuenta, no la latencia. La lentitud en una aplicación de Bubble que crece suele ser un problema de consulta o de diseño de página, no un techo de plataforma. **¿Qué límite de Bubble se alcanza primero?** En la práctica, el tope de 50.000 resultados en la búsqueda ordenada, porque los reportes y las exportaciones son donde aparecen conjuntos grandes y ordenados. Rara vez se anuncia: el reporte simplemente deja de estar completo. **¿Se pueden subir estos límites?** Los límites duros son duros. Lo que sí puedes cambiar es si tu aplicación necesita cruzarlos, y eso suele ser una decisión de modelo de datos o de consulta. El workload es distinto: puedes comprar más, y ahí es una decisión de costo y no técnica. ## El siguiente paso Si tu aplicación está rozando uno de estos límites y no logras distinguir si es el diseño o la plataforma, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para separar los dos antes de comprometerte con una reconstrucción. [Agenda una conversación](/es/contacto).