Supabase lança Compute em alpha privado para rodar agentes, jobs e APIs junto aos dados

O Supabase Compute chegou em alpha privado e resolve um problema conhecido de quem usa Edge Functions: trabalho que não cabe nelas. Segundo a Supabase, isso inclui tarefas que precisam de mais memória ou CPU, que rodam além de 400 segundos (um agente de IA, por exemplo) ou que estão escritas em outra linguagem. Hoje isso costuma virar uma segunda plataforma, com deploys, logs e depuração separados em dois provedores.

No Compute, cada serviço recebe um ambiente Linux completo e pode ser Node, Deno ou qualquer Dockerfile. Há dois tamanhos: 2 GB com 1 vCPU ou 4 GB com 2 vCPUs. O fluxo usa a Supabase CLI v2.120.0 ou superior: ativar compute = true em [experimental] no config.toml, criar o serviço com supabase compute new, trocar o código inicial em supabase/compute/ e publicar com supabase compute push. A Management API também tem endpoints alpha para deploy, listagem e remoção. Os logs aparecem na página Compute do dashboard.

Os limites do alpha são claros. É para avaliação, não produção, e pode mudar ou acabar. Só funciona em us-west-2. O serviço pode ser reiniciado a qualquer momento, então o trabalho longo deve ser salvo no Postgres. Todo serviço recebe todos os segredos do projeto. Não há autoscaling, GPU nem disco persistente. Serviços públicos suspendem quando ociosos, os privados continuam rodando. Sandboxes para agentes de IA não fazem parte do alpha.

O número de destaque vem da Dreambase: ao mover um agente de dados para o Compute, a mediana das consultas ao Postgres ficou em 2,9 ms, contra 65 ms de outra região.

Em 28 de outubro de 2026, o CEVIU noticiou "Supabase Compute permite rodar agentes, jobs e APIs dentro do próprio projeto", já apontando o private alpha sem custo e o ambiente Linux completo por serviço. A cobertura de agora acrescenta o lançamento oficial do alpha com os detalhes operacionais: restrição à região us-west-2, limites (sem autoscaling, GPU ou disco persistente) e o caso da Dreambase, com latência de 65 ms para 2,9 ms.

Para quem opera plataforma, a leitura é de menos peças móveis: deploy, segredos e logs no mesmo projeto do banco, sem um segundo provedor só para agentes e jobs. Por outro lado, o alpha não serve para produção, e o fato de todo serviço enxergar todos os segredos do projeto pede cuidado de quem pensa em segurança de pipeline. A ausência de autoscaling e de disco persistente também força desenhar o serviço para reinício, com estado no Postgres.