Aloja tus dashboards de Streamlit en Snowflake sin pagar de más

La trampa del auto-suspend

Esto es lo que dice la documentación. Después de tres días de inactividad de los usuarios, el proceso del servidor de Streamlit termina. Luego el compute pool se suspende según su propio valor de AUTO_SUSPEND.

Hay dos problemas con eso.

Primero, los tres días no son configurables, por ahora. No puedes bajarlos a un día ni a una hora. Tres días de un nodo inactivo son unos 8 créditos, o $24. No es un desastre por sí solo. Pero se acumula a lo largo del pool y de cada entorno donde despliegas.

Segundo, el AUTO_SUSPEND del propio pool solo empieza a contar cuando no hay servicios corriendo en él. El servicio de Streamlit se queda ahí hasta que se cumplen los tres días, así que el temporizador del pool nunca llega a ayudarte.

Al 15 de octubre de 2026, el auto-suspend no se dispara de forma confiable: vi un servicio y su contenedor pasar del día 3 y seguir gastando dinero el día 4, y el soporte de Snowflake me dijo que la causa son pestañas del navegador que quedan abiertas y siguen reintentando el websocket (incluso las reconexiones rechazadas con 401 reinician el temporizador de inactividad en el backend). Snowflake está trabajando en una solución, así que puede que ya esté resuelto cuando leas esto.

Hay una funcionalidad en private preview que agrega idle_auto_shutdown_time_seconds a nivel de app, como la que tiene el warehouse runtime. Puede que hayas visto aparecer la propiedad al describir una app de Streamlit. Una vez inscrito, puedes establecer un valor más corto. Pregúntale a tu equipo de cuenta de Snowflake. ¡Me encantaría poder fijarlo en unas pocas horas por app y tener la configuración más ligera posible!

Mientras tanto, no cuentes con el temporizador de tres días. Suspéndelo tú mismo si quieres ahorrar. Veámoslo con más detalle.

Suspende cada noche y deja que los usuarios lo despierten

El ahorro más simple es una tarea programada que suspende el pool cada noche:

CREATE OR REPLACE TASK suspend_streamlit_pool
  SCHEDULE = 'USING CRON 30 18 * * * America/New_York'
AS
  ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU SUSPEND;

El rol dueño de la tarea necesita OPERATE sobre el pool. Si la ejecutas como tarea serverless, también necesita EXECUTE MANAGED TASK.

Por la mañana, nadie tiene que hacer nada. La primera persona que abre un dashboard lo despierta. En mi experiencia, esa primera carga es un arranque en frío de unos 45 segundos. Después de eso, es rápido para todos los demás.

La parte que muchos pasan por alto y donde el ahorro se multiplica

Cuando suspendes el pool por la noche, todos los dashboards se apagan. Por la mañana, solo vuelven los que la gente abre, y solo esos empiezan a facturar de nuevo.

Supón que tienes 25 dashboards. Si dejas todo corriendo, pagas 9 nodos, porque con el tiempo alguien abre cada uno de ellos. Si suspendes de noche y la gente solo abre 4 dashboards al día siguiente, pagas 2 nodos. Los otros 21 dashboards no cuestan nada ese día.

Eso convierte la suspensión nocturna en un truco mucho más poderoso que el simple ahorro de las horas nocturnas suspendidas. También dejas de pagar por los dashboards que nadie mira. Los reportes de fin de mes, la revisión trimestral, el dashboard olvidado que alguien construyó para un proyecto hace meses: solo cuestan dinero los días en que alguien realmente los ve.

Tu factura ahora depende de cuántos dashboards se abren por día, no de cuántos tienes desplegados.

Ventajas

• Factura predecible. Conoces el peor escenario.
• Funciona incluso mientras exista el bug del auto-suspend.
• Una sola instrucción suspende todos los nodos del pool, tengas 3 dashboards o 30.
• Los dashboards poco usados dejan de costar dinero.
• No hay nada que recordar. Nadie tiene que entrar a apagar cosas.

Desventajas

• El primer usuario de cada dashboard cada día espera unos 45 segundos. A mis usuarios no les molesta.
• Quien trabaje hasta tarde o en fin de semana se topa con el mismo arranque en frío.
• Suspender apaga todos los nodos del pool. Cualquiera que esté a mitad de sesión se encontrará de repente con una página de reinicio, así que elige una hora en la que la gente ya se haya ido. En mi opinión, el riesgo es bajo y la recarga es lo bastante rápida como para que valga la pena.

Si 45 segundos es demasiado para quienes abren los dashboards a primera hora, puedes enviar una solicitud autenticada a los endpoints de esas apps unos minutos antes de que lleguen. A mí me funcionó, pero requiere configurar OAuth, lo cual agrega complejidad. Precalienta solo los pocos que importan, o perderás el ahorro en dashboards que nadie lee. Para mí, precalentar los dashboards es más complicado de lo que vale (por el flujo de OAuth que necesita), pero la opción existe.

Escenarios de costos

Supuestos: $3 por crédito, 25 dashboards desplegados, tres dashboards por nodo. "Suspendido" significa que los nodos corren 12 horas al día solo entre semana (22 días al mes). Es un límite superior, porque un dashboard abierto a las 2 pm no factura por la mañana.

Ahora compáralo con dejar los 25 corriendo las 24 horas. Con el tiempo todos los dashboards se abren, así que pagas 9 nodos todo el mes: $2,138. Si en un día típico solo se usan 4 dashboards, la suspensión nocturna te lleva de $2,138 a $174.

Llena tus nodos. El dashboard número 4 te cuesta lo mismo que el número 6, así que si vas a pagar un segundo nodo, llénalo.

Punto de equilibrio frente a Power BI

Power BI Pro se factura por usuario. Al precio de lista de $14 por usuario al mes, cada persona que ve un reporte necesita una licencia. Streamlit en Snowflake se factura por nodo. No hay cuota de plataforma ni cuota por usuario.

Así que empieza por tu número de usuarios. Esto es lo que cuesta Power BI a $24 por usuario al mes (Premium), y cuántos dashboards corre el mismo dinero en Snowflake con la suspensión nocturna:

Léelo así. Si 4 dashboards los usan 50 personas, Power BI Pro cuesta unos $700 al mes y Snowflake $174. Si los 25 dashboards los usan 40 personas, Power BI cuesta unos $560 y Snowflake $784, o $2,138 si nunca suspendes. Cuantas más personas por dashboard, mejor queda Snowflake. Cuantos más dashboards por persona, mejor queda Power BI.

Dos advertencias honestas:

• Streamlit es código. Power BI es arrastrar y soltar. Si tus analistas no saben escribir Python (o no están plenamente potenciados por la IA), el ahorro en hosting puede no importar.
• Power BI Premium Per User cuesta $24 por usuario al mes, y la capacidad de Fabric elimina la licencia de visualización en despliegues grandes, pero parte de unos $5,000 al mes. Verifica los precios actuales antes de armar el caso de negocio.

Puntos clave

1. Usa container runtime para los dashboards que la gente abre con frecuencia. El container runtime es mi nueva opción por defecto: prefiero su menor costo por hora y no quiero mezclarlo con mi uso de Warehouses. También me gusta la experiencia de usuario con menos arranques en frío, comparada con warehouses que suspendes de forma agresiva.
2. Tres dashboards por nodo. El cuarto arranca un nodo nuevo.
3. El nodo más pequeño cuesta unos 0.11 créditos por hora, 2.64 por día, cerca de $238 al mes a $3 por crédito. Sí, el nodo más pequeño puede alojar tus dashboards sin problema. El tamaño de los datos no importa; las consultas siguen corriendo en Virtual Warehouses.
4. No dependas del auto-suspend de tres días. Suspende el pool con una tarea programada.
5. Después de una suspensión, solo los dashboards que la gente abre vuelven a facturar. Pagas por lo que se usa, no por lo que está desplegado.
6. Presupuesta un arranque en frío de 45 segundos y avísales a tus usuarios.
7. Pasadas unas cuantas decenas de usuarios, la facturación por nodo le gana a la facturación por licencia.

Si quieres ayuda para dimensionar una configuración de Streamlit o descubrir a dónde se van tus créditos de Snowflake, nos encantaría saber de ti. ¡Escríbenos!