Ajudei três empresas a sair do Bubble no último ano. Todas começaram do mesmo jeito: alguém do time abriu a fatura mensal, viu um número que fez o coração disparar, e começou a buscar por "Bubble alternative" no Google. Se é você agora, respire. Você não está sozinho, e isso é realmente um problema que pode ser resolvido.

Bubble é genuinamente ótimo para colocar um MVP no ar. Recomendei para founders em estágio inicial mais vezes do que consigo contar. Mas há um padrão que continuo vendo: o produto cresce, o time cresce, a base de usuários cresce -- e de repente Bubble não está crescendo junto. Está te segurando. O modelo de precificação de workflow unit (WU) que parecia fine com 1.000 usuários vira um problema sério com 50.000. O editor visual que se sentia libertador começa a parecer uma gaiola quando você precisa de lógica customizada. Os tempos de carregamento de página que eram "aceitáveis" viram constrangedores.

Este artigo é o guia de migração que gostaria de ter tido a primeira vez que fiz isso. Vamos falar sobre por que times saem do Bubble, qual é o custo real em 2026, e como executar uma migração para Next.js e Supabase sem queimar sua empresa.

Índice

Saiu do Bubble? Como Migrar para Next.js e Supabase em 2026

Por Que Times Saem do Bubble

Vamos ser específicos sobre o que "sair" realmente significa, porque não é uma única coisa. Geralmente é uma combinação de vários pontos de dor que se agravam.

Limites de Performance

Apps do Bubble rodam em infraestrutura compartilhada. Seu app compartilha recursos de computação com outros apps do Bubble. Quando seu app recebe picos de tráfego, você não pode simplesmente iniciar mais instâncias -- você está à mercê do Bubble. Vi apps do Bubble com 500+ usuários simultâneos atingindo tempos de resposta de 3-5 segundos para consultas simples de banco de dados. Isso não é um bug; é a arquitetura.

Páginas do Bubble também são pesadas. Uma página típica do Bubble envia 2-4MB de JavaScript para o cliente. Compare isso com uma página Next.js bem construída que pode enviar 200-400KB. Seus usuários sentem essa diferença, especialmente em mobile.

O Problema dos Plugins

O ecossistema de plugins do Bubble é tanto sua força quanto seu calcanhar de Aquiles. Você vai instalar plugins para integração com Stripe, para geração de PDF, para enviar emails -- e cada um é mantido por um desenvolvedor terceirizdo aleatório que pode abandonar na próxima terça. Vi apps em produção quebrarem porque um autor de plugin fez um push de uma atualização ruim. Você não tem controle nenhum.

Vendor Lock-in É Real

Sua aplicação inteira -- a lógica, os dados, a UI -- vive dentro do sistema proprietário do Bubble. Não há um botão "exportar meu app". Seus workflows não são código; são configurações visuais armazenadas no formato do Bubble. Se Bubble mudar seu preço (o que já fizeram, várias vezes), você paga a mais ou começa do zero. Essa é uma péssima posição negocial para qualquer negócio.

Problemas de Scaling do Time

Tente contratar um "desenvolvedor Bubble" em 2026. O pool de talentos é minúsculo comparado a desenvolvedores React/Next.js. Controle de versão no Bubble é primitivo comparado a Git. Ter vários desenvolvedores trabalhando no mesmo app do Bubble simultaneamente é um exercício em frustração. Não há processo real de code review, nenhuma estratégia de branching, nenhum pipeline de CI/CD.

A Realidade da Precificação do Bubble em 2026

Bubble mudou para precificação de workflow unit (WU) em 2023, e ajustou várias vezes desde então. A partir do início de 2026, aqui está o que você está vendo:

Plano Custo Mensal Workflow Units Taxa WU Server-Side Taxa WU Client-Side
Free $0 Limitado (apenas testes) N/A N/A
Starter $32/mês 10.000 WU 1 WU por ação 0.2 WU por ação
Growth $129/mês 50.000 WU 1 WU por ação 0.2 WU por ação
Team $349/mês 150.000 WU 1 WU por ação 0.2 WU por ação
Enterprise Custom Custom Custom Custom
Overage Por WU — $0.003/WU $0.003/WU

Aqui é onde fica feio. Um app SaaS moderadamente complexo com 10.000 usuários ativos pode facilmente consumir 500.000-1.000.000 WU por mês. Isso é $1.050-$2.550 em custos de overage além do plano Team. Vi empresas pagando $3.000-$8.000/mês no Bubble para apps que poderiam rodar em $50-200/mês de infraestrutura em nuvem.

O modelo WU é particularmente punitivo porque cobra você por coisas que seriam essencialmente grátis em um stack customizado. Buscar seu banco de dados? Custa WUs. Agendar um workflow recorrente? WUs. Enviar uma notificação? WUs. Cada chamada de API, cada verificação condicional no server side -- tudo se acumula.

E aqui está a parte que realmente dói: o preço do Bubble só se moveu em uma direção. O modelo WU substituiu a precificação antiga baseada em capacidade, e muitos usuários viram suas contas aumentar 2-5x da noite para o dia. Não há garantia de que não vai acontecer novamente.

Por Que Next.js + Supabase É o Caminho

Avaliei dezenas de estratégias de saída do Bubble ao longo dos anos. Rails, Django, Laravel, React puro com Firebase -- são todas válidas. Mas para times vindo do Bubble especificamente, a combinação Next.js + Supabase atinge um sweet spot que é difícil de bater.

Next.js Te Dá O Que Bubble Não Pode

Next.js 15 (a release estável atual em 2026) te dá server-side rendering, static generation, API routes, middleware, e edge functions tudo em um framework. Suas páginas carregam rápido porque você só está enviando o JavaScript que a página realmente precisa. O App Router te dá layouts, loading states, e error boundaries que levariam dezenas de workflows do Bubble para aproximar.

Mais importante, é React. O ecossistema React é enorme. Precisa de um date picker? Há 50 opções battle-tested. Precisa de gráficos? Recharts, Visx, Nivo -- escolha o seu. Precisa de auth? NextAuth.js (agora Auth.js) ou Supabase Auth. Você nunca fica preso esperando um desenvolvedor de plugin consertar um bug.

Se você está considerando esse caminho, nosso time de desenvolvimento Next.js migrou vários apps do Bubble e pode compartilhar detalhes específicos de como o processo se parece.

Supabase Substitui o Backend do Bubble

Supabase é a coisa mais próxima de um "substituto de backend do Bubble" que existe. Aqui está por que:

  • Banco de dados PostgreSQL -- um banco de dados relacional real, consultável, indexável ao invés da estrutura estranha do Bubble
  • Row Level Security (RLS) -- defina quem pode ler/escrever quais dados no nível do banco de dados
  • Auth integrada -- email/password, magic links, provedores OAuth, tudo gerenciado
  • Inscrições em tempo real -- atualizações de dados ao vivo sem polling
  • Storage -- uploads de arquivo com entrega via CDN
  • Edge Functions -- funções serverless para lógica customizada

A precificação do Supabase em 2026 é dramaticamente mais barata que Bubble em escala:

Bubble (Growth) Supabase (Pro) + Vercel (Pro)
Custo base mensal $129 $25 + $20 = $45
Em 10K usuários $349+ (overage provável) ~$75-150 (com uso)
Em 50K usuários $2.000-5.000+ ~$200-500
Em 100K usuários $5.000-12.000+ ~$400-1.200
Acesso ao banco de dados Queries proprietárias PostgreSQL completo
Código customizado Muito limitado Ilimitado

Esses números não são teóricos. Eles são baseados em contas reais que vi de empresas com as quais trabalhei.

Saiu do Bubble? Como Migrar para Next.js e Supabase em 2026 - arquitetura

Comparação de Arquitetura: Bubble vs Next.js + Supabase

Vamos mapear conceitos do Bubble para o novo stack para você ver o que vai para onde:

Conceito do Bubble Equivalente Next.js + Supabase
Pages Next.js pages/routes (App Router)
Reusable Elements Componentes React
Elementos Visuais JSX + Tailwind CSS / component libraries
Workflows API routes, Server Actions, Edge Functions
Database Things Tabelas PostgreSQL
Data Types & Fields Colunas da tabela com tipos apropriados
Privacy Rules Supabase Row Level Security (RLS)
Backend Workflows Supabase Edge Functions ou cron jobs
API Connector Chamadas nativas fetch/axios
Plugins pacotes npm
User auth Supabase Auth ou Auth.js
File uploads Supabase Storage
Scheduling pg_cron ou externo (Inngest, Trigger.dev)

O Playbook de Migração

Não tente reconstruir tudo de uma vez. Vi isso falhar espetacularmente. Aqui está a abordagem em fases que realmente funciona.

Fase 1: Auditoria e Planejamento (1-2 semanas)

Antes de escrever uma única linha de código, documente tudo que seu app do Bubble faz. Tudo mesmo:

  1. Mapeie cada página -- screenshots, fluxos de usuário, quais dados cada página lê/escreve
  2. Catalogar todos os workflows -- server-side e client-side, o que os dispara, o que fazem
  3. Documente o modelo de dados -- cada data type, cada field, cada relacionamento
  4. Liste todas as integrações -- Stripe, SendGrid, Twilio, qualquer plugin que você usa
  5. Identifique o que cortar -- Eu garanto que há features que ninguém usa. Não migre peso morto.

Fase 2: Construir a Fundação (2-3 semanas)

Levante o novo stack:

npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npm install @supabase/supabase-js @supabase/ssr

Configure seu projeto Supabase, configure auth, crie seu schema de banco de dados. Aqui é onde você consegue corrigir todos os erros de modelagem de dados que cometeu no Bubble. Aproveite foreign keys apropriadas, índices, e tipos de dados.

Fase 3: Construir Features Principais (4-8 semanas)

Comece com as features que recebem mais tráfego. Construa-as apropriadamente em Next.js. Não tente replicar a UI exata do Bubble -- use essa oportunidade para melhorar a UX.

Fase 4: Migrar Dados e Usuários (1-2 semanas)

Essa é a parte assustadora, e merece sua própria seção.

Fase 5: Fazer o Switch (1 semana)

Execute ambos os sistemas em paralelo, verifique se tudo funciona, depois mude o DNS. Mantenha o app do Bubble rodando em modo read-only por algumas semanas como rede de segurança.

Migração de Dados: Saindo do Banco de Dados do Bubble

Bubble permite exportar seus dados como arquivos CSV. Esse é seu ponto de partida, mas não é tão limpo quanto você esperaria.

# Script Python de exemplo para transformar exportações CSV do Bubble
import csv
import json
from supabase import create_client

supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

with open('bubble_users_export.csv', 'r') as f:
    reader = csv.DictReader(f)
    for row in reader:
        # Bubble exporta datas em um formato estranho
        created = convert_bubble_date(row['Created Date'])
        
        # Bubble usa IDs únicos que parecem "1677234567890x123456789"
        # Você vai querer mapear esses para UUIDs
        user_data = {
            'legacy_bubble_id': row['unique id'],
            'email': row['email'],
            'name': row['name_text'],
            'created_at': created,
            # Mapeie todos seus campos customizados
        }
        
        supabase.table('users').insert(user_data).execute()

Pegadinhas principais com exportações de dados do Bubble:

  • Relacionamentos são armazenados como IDs do Bubble -- você vai precisar construir uma tabela de mapeamento para converter esses para suas novas foreign keys
  • Campos de arquivo exportam como URLs da CDN do Bubble -- você precisa baixar esses arquivos e re-upload-ar para Supabase Storage antes do app do Bubble ir offline
  • Campos de lista exportam como IDs do Bubble separados por vírgula -- esses precisam virar tabelas de junção apropriadas
  • Formatos de data são inconsistentes -- teste seu parsing de data minuciosamente

Para a Data API do Bubble, você também pode puxar dados programaticamente, o que às vezes é mais fácil que exportações CSV para datasets grandes:

// Buscando dados da Data API do Bubble
const fetchBubbleData = async (type, cursor = 0) => {
  const response = await fetch(
    `https://yourapp.bubbleapps.io/api/1.1/obj/${type}?cursor=${cursor}&limit=100`,
    {
      headers: {
        'Authorization': `Bearer ${BUBBLE_API_KEY}`
      }
    }
  );
  return response.json();
};

Reconstruindo Seu Frontend em Next.js

O editor visual do Bubble mapeia surpreendentemente bem para arquitetura baseada em componentes uma vez que você vê o padrão. Um "Reusable Element" do Bubble é literalmente um componente React. Um "Group" do Bubble é uma <div> com classes Tailwind.

Aqui está um padrão que uso para páginas que eram data-heavy no Bubble:

// app/dashboard/page.tsx
import { createClient } from '@/lib/supabase/server';
import { DashboardStats } from '@/components/dashboard-stats';
import { RecentActivity } from '@/components/recent-activity';

export default async function DashboardPage() {
  const supabase = await createClient();
  
  const { data: stats } = await supabase
    .from('user_stats')
    .select('*')
    .single();
  
  const { data: activity } = await supabase
    .from('activity_log')
    .select('*, project:projects(name)')
    .order('created_at', { ascending: false })
    .limit(20);

  return (
    <div className="max-w-7xl mx-auto px-4 py-8">
      <h1 className="text-3xl font-bold mb-8">Dashboard</h1>
      <DashboardStats stats={stats} />
      <RecentActivity items={activity} />
    </div>
  );
}

Note como o data fetching acontece server-side. Sem loading spinners, sem requisições em cascata. A página chega completamente renderizada. Isso sozinho faz o app parecer dramaticamente mais rápido que a versão do Bubble.

Para component libraries, tive ótimos resultados com shadcn/ui. Ele te dá componentes polidos e acessíveis que você possui (eles são copiados para seu codebase, não importados de um pacote). Combinado com Tailwind CSS, você consegue reconstruir UIs do Bubble rapidamente e elas serão mais responsivas e performáticas.

Configurando Supabase como Seu Backend

Row Level Security do Supabase é seu substituto para Privacy Rules do Bubble, e honestamente, é muito mais poderoso:

-- Deixe usuários verem apenas seus dados
CREATE POLICY "Users can view own data"
  ON user_profiles FOR SELECT
  USING (auth.uid() = user_id);

-- Deixe usuários atualizar seu próprio perfil
CREATE POLICY "Users can update own profile"
  ON user_profiles FOR UPDATE
  USING (auth.uid() = user_id);

-- Deixe admins ver tudo
CREATE POLICY "Admins can view all"
  ON user_profiles FOR SELECT
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE user_id = auth.uid()
      AND role = 'admin'
    )
  );

Para workflows de backend (coisas que rodavam em um agendamento no Bubble), Supabase Edge Functions com pg_cron funcionam bem para a maioria dos casos de uso. Para agendamento de jobs mais complexo, Trigger.dev ou Inngest são escolhas excelentes que se integram naturalmente com Next.js.

Autenticação e Migração de Usuários

Essa é a parte mais complicada de toda a migração. Seus usuários têm senhas armazenadas no Bubble, e você não consegue exportar hashes de senha. Você tem duas opções:

  1. Forçar reset de senha -- Envie para todos os usuários um email "atualizamos nossa plataforma" com um link de reset de senha. Simples mas cria atrito.
  2. Migração Lazy -- Configure um fluxo de auth customizado que, no primeiro login, tenta autenticar contra a API do Bubble. Se bem-sucedido, cria o usuário no Supabase com a senha que ele acabou de digitar.

A opção 2 é mais trabalho mas uma experiência de usuário muito melhor. Aqui está a forma áspera:

// app/api/auth/migrate-login/route.ts
export async function POST(request: Request) {
  const { email, password } = await request.json();
  
  // Tente Supabase primeiro
  const { data, error } = await supabase.auth.signInWithPassword({
    email, password
  });
  
  if (data.user) return Response.json({ success: true });
  
  // Se não estiver no Supabase, tente Bubble
  const bubbleAuth = await authenticateWithBubble(email, password);
  
  if (bubbleAuth.success) {
    // Crie usuário no Supabase com a mesma senha
    const { data: newUser } = await supabase.auth.admin.createUser({
      email,
      password,
      email_confirm: true,
    });
    
    // Migre seus dados de perfil
    await migrateUserProfile(bubbleAuth.userId, newUser.user.id);
    
    // Faça sign in deles
    return Response.json({ success: true });
  }
  
  return Response.json({ error: 'Invalid credentials' }, { status: 401 });
}

Performance e Custo Após Migração

Aqui estão números reais de um app de gerenciamento de projetos que ajudei a migrar no final de 2025:

Métrica No Bubble Após Migração
Tempo médio de carregamento de página 3.8s 0.9s
Time to Interactive 5.2s 1.4s
Lighthouse Performance 38 92
Custo mensal de infraestrutura $4.200 $187
Usuários ativos mensais 12.000 12.000
Tempo de resposta de API (p95) 1.800ms 180ms
Uptime (média 3 meses) 99.2% 99.97%

A redução de custo sozinha justificou a migração em dois meses. As melhorias de performance reduziram churn em um estimado 15% durante o trimestre seguinte.

Se você está olhando esses números e pensando "eu quero isso mas não tenho o time de dev para fazer", é exatamente o tipo de projeto que a gente faz. Confira nosso trabalho de desenvolvimento de Headless CMS e apps ou entre em contato para uma avaliação de migração.

Armadilhas Comuns e Como Evitá-las

Tentar Replicar Bubble Exatamente

Não faça. O jeito do Bubble de fazer as coisas é frequentemente o pior jeito de fazer em um stack baseado em código. Use a migração como uma chance de repensar fluxos de usuário e arquitetura de dados.

Subestimar a Migração de Dados

Orçamente o dobro do tempo que você acha que precisa para migração de dados. As exportações de dados do Bubble terão edge cases que vão te surpreender. Valores null onde você não esperava. Registros duplicados. Relacionamentos órfãos.

Esquecer Sobre Storage de Arquivo

Bubble hospeda seus arquivos enviados na CDN deles. Quando você cancela seu plano do Bubble, essas URLs morrem. Certifique-se de que cada arquivo é baixado e re-upload-ado para Supabase Storage antes de você fazer o switch.

Não Configurar Monitoring Cedo

No Bubble, você não pensa sobre monitoring porque não consegue fazer muita coisa sobre problemas de qualquer forma. No seu novo stack, configure Sentry para rastreamento de erros e Vercel Analytics (ou Plausible/PostHog) para monitoring de performance desde o primeiro dia.

Ir Sozinho Quando Não Deveria

Se seu app do Bubble é complexo e revenue-critical, seriamente considere conseguir ajuda de um time que já fez isso antes. O custo de uma migração fracassada -- dados perdidos, downtime, churn de usuários -- muito excede o custo de ajuda profissional. Nossa pricing page tem detalhes sobre como engagements parecem.

FAQ

Quanto tempo leva para migrar do Bubble para Next.js e Supabase?

Para um app SaaS típico com 10-30 páginas e complexidade moderada, espere 8-16 semanas para uma migração completa. Apps simples (landing page + dashboard + alguns features CRUD) podem ser feitos em 4-6 semanas. Apps complexos com muitas integrações, lógica customizada, e datasets grandes podem levar 16-24 semanas. A migração de dados e transição de user auth geralmente levam mais tempo do que o esperado.

Posso migrar do Bubble gradualmente, ou tem que ser tudo de uma vez?

Você pode absolutamente fazer gradualmente. Uma abordagem comum é construir o novo app Next.js ao lado do app do Bubble, migrar features uma por uma, e usar domain routing para enviar usuários para a versão certa. Por exemplo, seu novo dashboard vive em app.yoursite.com enquanto features legais ainda rodam no Bubble. Apenas esteja ciente de que manter dois sistemas simultaneamente tem seus próprios custos.

E quanto a alternativas do Bubble como FlutterFlow, WeWeb, ou Xano -- devo considerar esses ao invés?

Se seu principal problema é o preço do Bubble mas você ainda quer uma abordagem no-code/low-code, ferramentas como WeWeb (frontend) + Xano (backend) podem funcionar. Mas você está trocando um vendor lock-in por outro. Se você está saindo do Bubble porque de performance, escalabilidade, ou tamanho do time, você eventualmente vai sair dessas ferramentas também. Passar para um stack baseado em código como Next.js + Supabase é um investimento uma única vez que escala indefinidamente.

Quanto custa rodar um app Next.js + Supabase comparado ao Bubble?

Para a maioria dos apps SaaS, você está olhando $45-200/mês em Vercel + Supabase para o que custaria $349-5.000+/mês no Bubble. Supabase Pro é $25/mês, Vercel Pro é $20/mês. Em escala, seus custos crescem muito mais lentamente porque você está pagando por recursos de computação reais ao invés de workflow units. Uma regra de ouro áspera: espere pagar 5-20% do que você estava pagando no Bubble.

Meu SEO vai ser afetado pela migração?

Pode melhorar dramaticamente. Apps do Bubble são client-rendered e lentos, o que prejudica Core Web Vitals scores. Next.js suporta server-side rendering e static generation, o que significa page loads mais rápidos e melhor crawlability. Apenas certifique-se de que você configura proper 301 redirects das suas antigas URLs do Bubble para as novas rotas Next.js, e você deveria ver melhorias de SEO dentro de algumas semanas.

Eu preciso saber PostgreSQL para usar Supabase?

Conhecimento básico de SQL ajuda muito, mas Supabase fornece um editor de tabela visual e uma client library JavaScript que abstrai a maioria das queries. Dito isso, entender SQL vai te fazer dramaticamente mais efetivo. Para queries complexas, reporting, e performance tuning, conhecimento de SQL é essencial. Se seu time não tem experiência com SQL, esse é um bom tempo para investir em aprender -- é uma skill que gera dividendos para sempre.

O que acontece com as integrações de API do meu app do Bubble durante a migração?

Você vai precisar recriar cada integração no seu app Next.js. A boa notícia é que isso é geralmente muito mais fácil com código do que com o plugin API Connector do Bubble. Uma integração com Stripe que requeria um plugin e 15 workflows no Bubble pode ser 50 linhas de código com o SDK Node.js do Stripe. Faça uma lista completa de cada serviço externo que seu app do Bubble conversa e enfrente um de cada vez.

Eu posso usar o free tier do Supabase para produção?

O free tier do Supabase em 2026 te dá 500MB de armazenamento de banco de dados, 1GB de armazenamento de arquivo, e 50.000 usuários ativos mensais em auth. Para produtos em estágio muito inicial, isso pode funcionar. Mas para qualquer app de produção sério, você vai querer o plano Pro em $25/mês para melhor performance, backups diários, e sem project pausing após inatividade. Ainda é absurdamente barato comparado ao Bubble.