Hospede dashboards Streamlit no Snowflake sem desperdiçar créditos

A pegadinha do auto-suspend

Veja o que a documentação diz. Após três dias de inatividade dos usuários, o processo do servidor Streamlit é encerrado. Então o compute pool é suspenso de acordo com o seu próprio valor de AUTO_SUSPEND.

Dois problemas com isso.

Primeiro, os três dias não são configuráveis, por enquanto. Você não pode mudar para um dia ou uma hora. Três dias de um nó ocioso são cerca de 8 créditos, ou $24. Não é um desastre por si só. Mas vai se acumulando ao longo de um pool e de todos os ambientes em que você faz deploy.

Segundo, o AUTO_SUSPEND do próprio pool só começa a contar quando não há serviços rodando nele. O serviço do Streamlit fica lá até os três dias acabarem, então o timer do pool nunca tem a chance de ajudar.

Em 15 de outubro de 2026, o auto-suspend não dispara de forma confiável: vi um serviço e seu container passarem do dia 3 e continuarem gastando dinheiro no dia 4, e o suporte da Snowflake me disse que a causa são abas do navegador deixadas abertas que continuam tentando reconectar o websocket (até reconexões rejeitadas com 401 reiniciam o timer de inatividade no backend). A Snowflake está trabalhando em uma correção, então pode ser que já esteja resolvido quando você ler isto.

Existe um recurso em private preview que adiciona idle_auto_shutdown_time_seconds no nível do app, como o warehouse runtime tem. Você pode ter notado essa propriedade ao rodar um describe em um app Streamlit. Depois de incluído no preview, você pode definir um valor menor. Pergunte ao seu time de conta da Snowflake. Eu adoraria poder definir isso para algumas horas em cada app e ter a configuração mais enxuta possível!

Até lá, não conte com o timer de três dias. Suspenda você mesmo se quiser economizar. Vamos nos aprofundar nisso.

Suspenda todas as noites e deixe os usuários acordarem o pool

A forma mais simples de economizar é uma task agendada que suspende o pool toda noite:

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

A role dona da task precisa de OPERATE no pool. Se você executá-la como serverless task, ela também precisa de EXECUTE MANAGED TASK.

De manhã, ninguém precisa fazer nada. A primeira pessoa a abrir um dashboard acorda o pool. Na minha experiência, esse primeiro carregamento é um cold start de cerca de 45 segundos. Depois disso, fica rápido para todo mundo.

A parte que as pessoas não percebem e onde a economia se multiplica

Quando você suspende o pool à noite, todos os dashboards são desligados. De manhã, só os que as pessoas abrem voltam a rodar, e só esses voltam a ser cobrados.

Digamos que você tenha 25 dashboards. Se deixar tudo rodando, paga por 9 nós, porque, com o tempo, alguém abre cada um deles. Se suspender à noite e as pessoas abrirem apenas 4 dashboards no dia seguinte, você paga por 2 nós. Os outros 21 dashboards não custam nada naquele dia.

Isso torna a suspensão noturna um truque muito mais poderoso do que apenas economizar as horas em que o pool ficou suspenso. Você também para de pagar pelos dashboards que ninguém olha. Relatórios de fim de mês, a revisão trimestral, aquele dashboard parado que alguém criou para um projeto meses atrás: eles só custam dinheiro nos dias em que alguém realmente os visualiza.

Sua fatura passa a acompanhar quantos dashboards são abertos por dia, não quantos você implantou.

Prós

• Fatura previsível. Você conhece o pior cenário.
• Funciona mesmo enquanto o bug do auto-suspend existir.
• Um único comando suspende todos os nós do pool, sejam 3 dashboards ou 30.
• Dashboards raramente usados deixam de custar dinheiro.
• Nada para lembrar de fazer: ninguém precisa entrar e desligar nada manualmente.

Contras

• O primeiro usuário de cada dashboard, a cada dia, espera cerca de 45 segundos. Meus usuários não se incomodam com isso.
• Quem trabalha até tarde ou no fim de semana enfrenta o mesmo cold start.
• Suspender derruba todos os nós do pool. Quem estiver no meio de uma sessão vai cair de repente em uma página de reinicialização, então escolha um horário em que as pessoas já tenham ido para casa. Na minha opinião, o risco é baixo e o refresh é rápido o suficiente para valer a pena.

Se 45 segundos for tempo demais para quem abre os dashboards logo cedo, você pode enviar uma requisição autenticada para os endpoints desses apps alguns minutos antes de as pessoas chegarem. Funcionou para mim, mas exige OAuth configurado, o que adiciona complexidade. Aqueça só os poucos que importam, ou você devolve a economia em dashboards que ninguém lê. Para mim, pré-aquecer os dashboards é mais complicado do que vale a pena (por exigir o fluxo de OAuth), mas a opção existe.

Cenários de custo

Premissas: $3 por crédito, 25 dashboards implantados, três dashboards por nó. "Suspenso" significa que os nós rodam 12 horas por dia apenas em dias úteis (22 dias por mês). Esse é um limite superior, porque um dashboard aberto às 14h não é cobrado pela manhã.

Agora compare com deixar os 25 rodando o tempo todo. Com o tempo, todos os dashboards são abertos, então você paga por 9 nós o mês inteiro: $2.138. Se apenas 4 dashboards forem usados em um dia típico, a suspensão noturna leva você de $2.138 para $174.

Encha seus nós. O dashboard número 4 custa o mesmo que o número 6, então, se você vai pagar por um segundo nó, aproveite para enchê-lo.

Ponto de equilíbrio vs. Power BI

O Power BI Pro é cobrado por usuário. Com o preço de tabela de $14 por usuário por mês, cada pessoa que visualiza um relatório precisa de uma licença. O Streamlit no Snowflake é cobrado por nó. Não há taxa de plataforma nem taxa por assento.

Então comece pelo número de pessoas no seu time. Veja quanto custa o Power BI a $24 por usuário por mês (Premium) e quantos dashboards o mesmo dinheiro mantém no Snowflake com a suspensão noturna:

Leia assim: se 4 dashboards são usados por 50 pessoas, o Power BI Pro custa cerca de $700 por mês, e o Snowflake, $174. Se os 25 dashboards são usados por 40 pessoas, o Power BI custa cerca de $560, e o Snowflake, $784, ou $2.138 se você nunca suspender. Quanto mais pessoas por dashboard, melhor para o Snowflake. Quanto mais dashboards por pessoa, melhor para o Power BI.

Duas ressalvas honestas:

• Streamlit é código. Power BI é arrastar e soltar. Se seus analistas não sabem escrever Python (ou não estão totalmente equipados com IA), a economia de hospedagem pode não importar.
• O Power BI Premium Per User custa $24 por usuário por mês, e a capacidade do Fabric elimina a licença de visualização para grandes implantações, mas começa em torno de $5.000 por mês. Verifique os preços atuais antes de montar o business case.

Principais conclusões

1. Use container runtime para dashboards que as pessoas abrem com frequência. Container runtime é meu novo padrão, pois prefiro o custo por hora mais barato e não quero misturá-lo com meu uso de Warehouse. Também gosto da experiência de menos cold starts em comparação com Warehouses com auto-suspend agressivo.
2. Três dashboards por nó. O quarto inicia um novo nó.
3. O menor nó custa cerca de 0,11 crédito por hora, 2,64 por dia, cerca de $238 por mês a $3 por crédito. Sim, o menor nó consegue hospedar seus dashboards sem problema. O tamanho dos dados não importa; as consultas continuam rodando em Virtual Warehouses.
4. Não confie no auto-suspend de três dias. Suspenda o pool com um agendamento.
5. Depois de uma suspensão, só os dashboards que as pessoas abrem voltam a ser cobrados. Você paga pelo que é usado, não pelo que está implantado.
6. Conte com um cold start de 45 segundos e avise seus usuários.
7. A partir de algumas dezenas de usuários, a cobrança por nó vence a cobrança por licença.

Se você quer ajuda para dimensionar uma configuração de Streamlit ou descobrir para onde estão indo seus créditos do Snowflake, adoraríamos conversar com você. Entre em contato!