Alternar tema

Stack de backend para fundador solo: Cloudflare Workers, Supabase, Node.js e banco de dados

Easton editorial illustration: a central API routing hub with one inbound request token and three clearly differentiated outbound branches

"A Cloudflare publica limites distintos de requests, CPU, memória, subrequests e tamanho para Workers Free e Paid, sem duração HTTP fixa enquanto o cliente permanece conectado."

O frontend está pronto. Agora você precisa implementar /api/submit, /api/checkout-webhook e /api/report-cron, além de armazenar users, usage_events e files. O que vai para Workers, Supabase ou um serviço Node separado?

Uma stack de backend não é uma plataforma única. Entrada, dados, arquivos, tarefas longas, autenticação e webhooks são distribuídos. Workers atende edge e lógica leve, Supabase Auth e Postgres, e Node.js o trabalho fora do runtime edge. Compare a tabela ao seu backlog.

1. Tabela de responsabilidades: onde colocar cada item

Comece por APIs, webhooks, cron, dados e arquivos:

ResponsabilidadeInício recomendadoMotivoRisco
EntradaCloudflare WorkersEdge global e baixa latênciaSeparar o que exceder CPU, memória ou dependências
APIs levesWorkers / Edge FunctionsEncaminhamento, validação e I/O curtoWorkers fica no edge; Edge Functions no projeto Supabase
WebhooksWorkers ou Edge FunctionsCallbacks, assinatura e escrita idempotenteEnfileirar o trabalho pesado
AutenticaçãoSupabase AuthAuth, RLS, permissões e social loginNão expor service role ou secret ao navegador
Dados de negócioSupabase PostgresRelações, transações, consultas e triggersD1 também exige migrations, constraints e permissões
ObjetosSupabase Storage / R2Uploads, imagens, exports e backupEscolher por acesso, egress, CDN e ferramentas
Tarefas longasWorker Node.js / plataforma de tarefasNavegador, arquivos, módulos nativos, consumersNão ligar tudo a um request síncrono
Serviço NodeNode.jsnpm, conexões longas e runtime completaOperar deploy, monitoramento, patches e escala

A tabela não manda colocar tudo em Workers. Workers tem limites; Supabase, cotas e pausas; Node.js, operação contínua. Você pode adiar Node, mas precisa reconhecer o sinal.

Decidir onde os dados ficam

  • Dados de negócio → Supabase Postgres ou banco relacional para relações, transações, consultas, triggers e foreign keys.
  • Arquivos → Supabase Storage ou R2 conforme permissões, egress, CDN, região e ferramentas.
  • Cache → KV; D1 pode guardar relação leve, sem substituir a fonte de verdade.

O comparativo D1, Postgres, R2, S3 e SQLite fica para o artigo de storage. Aqui só atribuímos categorias.

Separar webhook e tarefa longa

Stripe ou GitHub podem chegar a Workers ou Edge Functions. O handler valida assinatura, grava idempotência e responde. Navegador, arquivos grandes ou espera externa seguem em Queue, Workflow, Container ou Node.js.

Workers Paid oferece 30 s de CPU HTTP por padrão, configuráveis até 5 min; Cron ao menos horário chega a 15 min. HTTP não tem wall-clock fixo com cliente conectado, mas desconexões, retries, recursos e updates tornam frágil uma tarefa longa presa ao request.

Alertas dos planos gratuitos

Em julho de 2026, Workers Free inclui 100 mil requests/dia, 10 ms CPU, 128 MB e 50 subrequests. Supabase Free inclui 50 mil MAU, 500 MB de banco, 5 GB egress, 1 GB de arquivos e dois projetos ativos.

São orçamentos iniciais, não promessas. Supabase pausa após uma semana inativo e Workers exige Paid ao superar Free. Com usuários ou pagamentos, crie alertas, custos e degradação.

2. Cloudflare Workers: o que cabe e o que não cabe

Workers não é universal. Os limites práticos são CPU, memória, subrequests e bundle.

Limites Workers Free em julho de 2026

São 100 mil requests/dia e 10 ms CPU por invocation, 128 MB, 50 subrequests e bundle comprimido de 3 MB. Excesso de CPU retorna 1102. HTTP não tem wall-clock fixo com o cliente conectado; ctx.waitUntil() prolonga até 30 s após resposta ou desconexão.

Limites Workers Paid Standard

O mínimo é US$ 5 por conta/mês, com 10 milhões de requests e 30 milhões de ms CPU. CPU HTTP: 30 s por padrão, até 5 min. Extras: US$ 0,30 por milhão de requests e US$ 0,02 por milhão de ms. São 10 mil subrequests, 10 MB e 128 MB.

Casos adequados

  • Entrada, proxies edge e APIs leves.
  • Webhooks, assinatura e enqueue idempotente.
  • Cron, Queues e Workflows.
  • KV/R2, cache, redirects e A/B.

Predominam I/O, validação e orquestração, sem grandes buffers, navegador ou biblioteca nativa.

Casos inadequados

  • CPU contínua → dividir, assíncrono ou Node.js/Container.
  • Arquivo inteiro em memória → stream ou upload direto.
  • Navegador longo → Node.js com Playwright/Puppeteer.
  • Dependência fora do runtime → Node.js ou container.

Compatibilidade Node não torna toda carga adequada. Avalie recurso, retry, duração e observabilidade.

Alerta de custo

A 5 ms, 10 milhões de requests consomem 50 milhões de ms CPU. Após 30 milhões incluídos, o extra é cerca de US$ 0,40, além de KV, Queues ou R2.

O risco é uma função central que só funciona na cota grátis. Planeje rate limit, cache e fallback.

3. Supabase: limites de Auth, Postgres, Storage e Edge Functions

Supabase reúne Postgres, Auth, Storage, Realtime e Edge Functions, cada qual com limites.

Limites Supabase Free em julho de 2026

São 500 MB de banco, 50 mil MAU, 5 GB egress, 5 GB cached egress e 1 GB de arquivos, com dois projetos ativos. Após uma semana sem atividade, pausa: serve para validar, não garantir produção.

Cota Supabase Pro

Começa em US$ 25/mês: 100 mil MAU, 8 GB disk, 250 GB egress, 250 GB cacheados e 100 GB de arquivos. Inclui US$ 10 de compute credits; extras aumentam a conta.

Casos adequados

  • Email, OAuth, sessions e RLS.
  • Relações, constraints, transactions e queries.
  • Arquivos com policies.
  • Triggers, funções e migrations Postgres.
  • Edge Functions ligadas a Auth, Postgres e Storage.

Quando a lógica escreve dados do usuário, atualiza rows ou registra uploads, Supabase reduz componentes.

Limites de Edge Functions

Runtime TypeScript/Deno: 256 MB, 2 s CPU por request e idle timeout 150 s. Duração máxima: 150 s Free e 400 s Paid.

Wall-clock inclui espera I/O, não CPU. Navegador, multithreading nativo, vídeo e arquivos grandes vão para worker dedicado. Background tasks mantêm limites.

Edge Functions ou Workers

  • Lógica ligada ao Supabase → Edge Functions.
  • Entrada edge ou proxy independente → Workers.

Webhook que atualiza assinatura cabe em Edge Functions; assinatura, rate limit e forward em Workers. O longo vai à fila.

Pausa do projeto

Free pausa após uma semana inativo. Ferramenta eventual pode aguardar retomada; produto estável deve avaliar Pro, backups e migration.

4. Node.js: quando ainda faz sentido

Serverless reduz manutenção, mas não elimina runtime completa, dependências do sistema e processos persistentes.

Quando usar Node.js

  • Playwright ou Puppeteer.
  • Arquivos grandes, parsing e disco temporário.
  • Módulos nativos ou npm fora do edge.
  • Consumers persistentes, WebSockets e API admin.
  • Backend compartilhado com recursos e observabilidade uniformes.

Screenshot, PDF, coleta, vídeo e arquivos grandes costumam exigir mais CPU, memória, processos ou filesystem.

Sinais para Node.js

Considere quando jobs batem repetidamente em CPU, memória, duração, bundle ou compatibilidade, ou precisam de navegador, módulo nativo, conexão persistente ou fila confiável.

Não use só “mais de 30 segundos”. Cada produto tem limites diferentes; importa caber no modelo de recurso, retry, idempotência e observabilidade.

Quando não usar Node.js

  • Forward de API ou routing edge.
  • Validação e writes leves.
  • Sem arquivos pesados, nativos ou conexão longa.
  • Sem demanda que justifique servidor.

Workers ou Edge Functions cobrem esses casos.

Node.js não está ultrapassado

Edge troca restrições por pouca operação e distribuição; Node.js troca infraestrutura por compatibilidade, controle e processos persistentes. Adicione quando navegador, arquivos ou dependências forem reais.

5. Workers e Supabase: API client ou Hyperdrive

Eles formam uma stack de edge mais identidade e dados, não apenas rivais.

Combinar Workers e Supabase

Workers faz encaminhamento, validação, rate limit e cache; Supabase Auth e Postgres cuidam de identidade, dados e policies. Funciona no primeiro produto sem servidor.

Para Auth, Data API ou Storage, supabase-js basta. Para SQL, transaction ou ORM frequentes, use driver e pool em vez de nova conexão por invocation.

Tabela de conexão

MétodoCasoObservação
Supabase JS ClientAuth, Storage e queries levesMantém JWT e RLS via API
Hyperdrive + driverSQL, ORM e Postgres diretoAgrupa conexões e pode cachear reads
service role / secret keyAdministração confiávelPode ignorar RLS; só client servidor isolado

Hyperdrive reduz latência e pressão ao conectar Supabase Postgres. Não autoriza: role, tables e RLS dependem de credenciais e policies.

Risco da service role key

Essas chaves são privilegiadas e podem ignorar RLS. Nunca exponha em navegador, celular, repositório ou log; mantenha como secret backend.

Use client servidor separado para uma session não substituir Authorization. Webhooks, batch e admin precisam de privilégio mínimo e auditoria.

Fronteira Edge Functions/Workers

  • Forte dependência do Supabase → Edge Functions.
  • Entrada, proxy, rate limit e routing independentes → Workers.

Decida pelo centro de dados e permissões, recursos edge e local de logs/deploy. Chave privilegiada sempre fica no backend.

6. Propriedade de dados: negócio, arquivos e cache

D1, Postgres, KV e R2 guardam dados, mas resolvem problemas diferentes.

Tabela de propriedade

TipoInícioCritérios
Fatos de negócioSupabase Postgres / D1 / outro relacionalRelações, transactions, constraints, queries, migrations e permissões
ArquivosSupabase Storage / R2 / S3Acesso, egress, CDN, ciclo e ferramentas
Cache/configuraçãoKV / CacheLeitura rápida, reconstrução e consistência aceitável

Usuários, pedidos, assinaturas, projetos e direitos afetam cobrança ou acesso. Use banco com constraints, migrations e backup. Postgres oferece queries, foreign keys, triggers, integridade e MVCC; D1 exige avaliação própria.

Não divida arquivos por 1 GB. Supabase Storage combina com Auth/RLS; R2 com tráfego/CDN Cloudflare. Decida por policy, egress, upload, transformação e SDK.

Cache não é banco de negócio. Se pedidos ou direitos só existem nele, expiração, atraso ou exclusão altera o estado real.

O comparativo completo fica para o artigo de storage.

7. Próximos passos da série

Depois vêm deploy, bancos e storage, pagamentos, autenticação e autorização.

Artigos relacionados

Veja Cloudflare Pages, Cloudflare Free Plan Limits 2026, proxy API Workers, início no Supabase e Supabase Edge Functions.

Criar primeiro sua tabela

Liste cinco ações e marque “resposta / identidade / fato / arquivo / tarefa / segredo”; atribua Workers, Supabase, Node.js ou adie. Plataforma é meio; responsabilidades e falhas definem a confiabilidade.

Distribuir responsabilidades do primeiro backend solo

Use ações e tipos de dados para atribuir APIs, autenticação, dados, arquivos e tarefas longas a serviços de baixa manutenção.

⏱️ Estimated time: 45 min

  1. 1

    Step 1: Listar ações

    Anote formulários, webhooks de pagamento, histórico, relatórios agendados, uploads e eventos de uso da semana.
  2. 2

    Step 2: Classificar responsabilidades

    Marque resposta imediata, identidade e acesso, fato de negócio, arquivo, tarefa assíncrona ou segredo.
  3. 3

    Step 3: Escolher o início

    Use Workers para edge e APIs leves, Supabase para Auth, Postgres e Storage, e Node.js para tarefas pesadas.
  4. 4

    Step 4: Verificar limites

    Confira CPU, memória, duração, banco, egress, arquivos e pausa para não depender da borda da cota.
  5. 5

    Step 5: Cobrir segurança e falhas

    Mantenha chaves fora do navegador, valide assinaturas, use idempotência, retry e logs.

FAQ

Workers Free basta para começar?
Geralmente basta para APIs leves, webhooks e proxies: 100 mil requests/dia e 10 ms CPU por invocation, além de 128 MB e limites próprios de subrequests, KV e Queues. É orçamento inicial, não SLA.
Workers pode ser todo o backend?
Pode executar muita lógica, mas navegador, arquivos grandes em memória, CPU pesada, dependências nativas e consumers persistentes combinam mais com Queues, Workflows, Containers ou Node.js.
Supabase e Workers competem?
Normalmente se complementam: Workers recebe e valida; Supabase oferece Auth, Postgres e Storage. A conexão pode usar APIs ou Hyperdrive com driver Postgres.
Webhook em Workers ou Edge Functions?
Workers é direto para assinatura, routing e encaminhamento; Edge Functions para lógica ligada ao Supabase. Responda rápido e enfileire o trabalho pesado.
Node.js está ultrapassado?
Não. Runtime completa, npm, navegador, módulos nativos, arquivos, conexões longas e consumers persistentes continuam úteis. Adie a operação até surgir um limite real.

8 min de leitura · Publicado em: 9 out 2026

Comentários

Entre com GitHub para comentar

Easton BlogEaston Blog