Limites de escala do Bubble: quais realmente pesam
O Bubble publica seus limites duros, e a maior parte deles nunca vai encostar no seu app. Os que decidem se uma operação continua crescendo são a busca ordenada travada em 50.000 itens, o campo de lista travado em 10.000 registros, o timeout de cinco minutos no workflow e uma conta que cresce conforme o app foi construído. O resto é ruído.
O app do Bubble fica mais lento conforme cresce?
Não, e vale dizer isso com clareza porque é a suposição com que a maioria dos times chega. A documentação de escala do Bubble resolve em uma linha: "We don't rate limit: Your app will run at the same pace no matter how much workload it consumes".
Isso muda a decisão. Se a performance caísse com o volume, o crescimento sozinho forçaria a migração num prazo previsível. Não cai. O que cresce com o volume é a conta, e conta é outro tipo de problema: negociável, às vezes com conserto, e fácil de empurrar por mais um trimestre.
Então a pergunta honesta não é "o Bubble vai ficar lento?". É "quais limites específicos estão entre a minha operação e onde ela precisa estar daqui a um ano?".
Quais limites duros são realmente alcançados?
Quatro, pela nossa experiência, e eles se concentram em listas e trabalho longo, não em volume bruto de dado.
Busca ordenada trava em 50.000 itens. O Bubble documenta que uma busca com ordenação retorna no máximo 50.000 itens. É o primeiro que a maioria encontra, porque relatório e exportação são exatamente onde se ordena um conjunto grande. Costuma aparecer como um relatório que silenciosamente deixa de estar completo, não como erro que alguém percebe.
Campo de lista trava em 10.000 registros. A mesma página fixa o limite de 10.000 registros para armazenamento em lista. Esse dói porque lista é a forma mais natural de modelar um relacionamento dentro de um editor visual, e o conserto é mudança de modelo de dados, não de configuração.
Workflow expira em 300 segundos. Qualquer coisa que rode mais de cinco minutos sofre timeout. Rotina em lote, fechamento de mês e importação grande vivem nessa borda, e chegam mais perto dela a cada mês que o negócio cresce.
Página trava em 10.000 elementos, eventos e ações somados. Esse é generoso, e um app que o alcança normalmente está dizendo algo sobre como a página foi construída, não sobre a plataforma.
Os limites com que as pessoas se preocupam antes raramente são os que chegam. Um campo de texto guarda 10 milhões de caracteres, um registro guarda 20 MB, upload vai a 5 GB e um app define até 1.000 tipos de dado próprios. Não são as restrições de uma operação em crescimento.
E os limites que não são técnicos?
São os que decidem a maior parte das migrações. O Bubble cobra trabalho de servidor em unidades de workload, e o FAQ de preços fixa o excedente base em US$ 0,30 por 1.000 unidades para quem não tem assinatura de tier.
O número em si não é o problema. O problema é a que ele está preso: o consumo acompanha como o app foi construído, então dois apps com tráfego idêntico podem cobrar valores bem diferentes porque alguém escolheu uma busca no lugar de uma consulta direta, ou levou para o servidor um cálculo que não precisava estar lá.
Há uma borda mais dura na mesma página. Com o overage desligado, o app que atinge o limite é tirado do ar e volta no início do próximo ciclo de cobrança. Isso transforma disponibilidade em configuração de cobrança, e é o comportamento documentado que mais vezes encerra a discussão internamente.
Bater num limite é motivo para sair?
Normalmente não, sozinho. Limite alcançado é sinal de desenho antes de ser veredito de plataforma, e a ordem da investigação economiza dinheiro de verdade.
Pergunte primeiro se o limite é estrutural ou acidental. Busca ordenada travando em 50.000 num relatório mensal costuma ser consulta que deveria ter filtrado antes de ordenar. Campo de lista em 10.000 registros costuma ser relacionamento que virou lista porque lista era mais fácil. Os dois têm conserto dentro do Bubble, e consertar compra tempo.
Pergunte depois quanto custa o conserto contra quanto custa ficar. Na plataforma da Colo Saúde o primeiro movimento foi deliberadamente ficar: o app foi estabilizado no Bubble e teve o consumo cortado em 60%, e só então a reconstrução começou. Essa sequência existe porque o fôlego decide se a migração é calma ou apressada.
Pergunte por último se os limites que você está batendo continuarão lá com três vezes o volume. Alguns tetos recuam quando você conserta a consulta. O timeout de cinco minutos não recua, ele chega mais rápido.
Quando as respostas apontam para o mesmo lado, o roteiro de decisão está em migrar do Bubble para código.
Perguntas frequentes
Meu app no Bubble vai ficar mais lento conforme cresce?
O Bubble afirma que não faz rate limit e que o app roda no mesmo ritmo independentemente do workload consumido. O que cresce com o uso é a conta, não a latência. Lentidão em app que cresce no Bubble costuma ser problema de consulta ou de desenho de página, não teto de plataforma.
Qual limite do Bubble é atingido primeiro?
Na prática, o teto de 50.000 resultados na busca ordenada, porque relatório e exportação são onde aparecem conjuntos grandes e ordenados. Ele raramente se anuncia: o relatório simplesmente deixa de estar completo.
Dá para aumentar esses limites?
Os limites duros são duros. O que dá para mudar é se o seu app precisa cruzá-los, e isso costuma ser decisão de modelo de dados ou de consulta. Workload é diferente: dá para comprar mais, e aí é decisão de custo, não técnica.
O próximo passo
Se o seu app está encostando em um desses limites e você não consegue dizer se é o desenho ou a plataforma, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para separar os dois antes de você se comprometer com uma reconstrução. Agende uma conversa.
Leia também
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem compromisso.
Agendar diagnóstico