Cloudflare, Supabase e Resend: uma stack serverless para lançar MVPs com menos custo e fricção

Resumo em uma frase: a infraestrutura inicial de um produto deve otimizar velocidade de validação, e não uma escala hipotética que talvez nunca chegue, e em 2026 uma stack serverless leva um MVP ao ar por volta de US$ 30 a 60 por mês, contra cerca de US$ 73 mensais que um cluster gerenciado de Kubernetes cobra só de control plane, antes do primeiro node.

Toda reunião de arquitetura de projeto novo passa pela mesma pergunta: quanto de infraestrutura esse produto realmente precisa no primeiro dia? A resposta tradicional envolve conta de nuvem, máquinas, runners, containers e um orquestrador. A resposta que vem ganhando espaço envolve três serviços gerenciados, um repositório conectado e um deploy que acontece em segundos.

Este artigo compara as duas com números apurados em fontes oficiais em 6 de agosto de 2026, e trata com o mesmo rigor o lado desconfortável: onde serverless quebra, quanto de lock-in existe de verdade e quais são os gatilhos objetivos para migrar.

A conta que quase ninguém faz no início

Antes de comparar plataformas, vale fixar o piso do caminho tradicional. Os três grandes provedores de Kubernetes gerenciado convergiram no mesmo preço de control plane: US$ 0,10 por cluster por hora no Amazon EKS, no Google GKE e no tier Standard do Azure AKS. São cerca de US$ 73 por mês antes de qualquer node, antes de banco, antes de load balancer e antes da primeira linha de código rodar.

Existem duas exceções que quase ninguém conhece: o tier Free do AKS não cobra control plane, com o custo de não ter SLA financeiramente garantido, e o GKE oferece US$ 74,40 por mês em créditos que cobrem um cluster zonal ou Autopilot por conta de faturamento.

O ponto não é que Kubernetes seja caro demais. É que ele cobra por uma capacidade de operação que um produto ainda não validado não usa. Pagar por elasticidade que você não vai exercer e por isolamento que você ainda não precisa é o oposto de otimizar para validação.

A stack em três peças

A lógica do arranjo é reduzir o número de peças que o time opera. Uma plataforma cuida da borda e dos arquivos, uma cuida de dados e identidade, uma cuida de e-mail. Nenhuma exige provisionar máquina, configurar rede ou manter sistema operacional atualizado.

Cloudflare: o que os limites realmente permitem

O plano gratuito é generoso em volume e restrito em processamento, e essa distinção é o que mais confunde.

Fonte: documentação oficial de limites e de preços do Cloudflare Workers, leitura de 6 de agosto de 2026.

Três detalhes mudam o projeto:

O limite de CPU não conta espera de rede. Chamadas HTTP, leituras de cache e consultas ao banco não consomem tempo de CPU. Os 10 ms do plano gratuito parecem impossíveis até você perceber que uma rota que só busca dados e devolve JSON gasta muito menos que isso. O que estoura os 10 ms é renderização pesada no servidor, criptografia e processamento de imagem.

Requisições a arquivos estáticos são gratuitas e ilimitadas. Só invocações do script do Worker são cobradas. Um site de conteúdo praticamente não gera custo.

O Cloudflare declarou em 2025 que todo o investimento vai para Workers, não para Pages. O Pages continua suportado, mas a recomendação oficial para projetos novos é começar por Workers, que hoje serve arquivos estáticos e renderização no servidor no mesmo produto. Vale seguir essa direção em vez de começar em um produto em modo de manutenção estratégica.

E o argumento econômico mais forte da plataforma não está no compute, e sim no armazenamento de arquivos:

Fonte: páginas oficiais de preços do Cloudflare R2 e do Amazon S3, leitura de 6 de agosto de 2026. O preço por GB de saída da AWS acima da franquia consta na tabela de transferência de dados, que varia por região.

A diferença nas operações é marginal. A manchete é a saída: para um produto que serve mídia, relatório ou download, egress é a linha que estoura a conta sem aviso, e é também o custo que mais aprisiona, porque sair de uma nuvem que cobra saída significa pagar para levar os próprios dados embora.

Uma ressalva de precisão: o R2 não cobra egress em nenhuma classe, mas a classe Infrequent Access cobra recuperação de dados por GB. Se o seu caso for arquivo morto acessado de vez em quando, compare recuperação, não só armazenamento.

Supabase: por que a conta não é US$ 25

O Supabase entrega em um único serviço aquilo que normalmente exige quatro: Postgres gerenciado, autenticação, storage de arquivos e busca vetorial. O plano Pro custa US$ 25 por mês, e é aqui que a leitura apressada erra.

Dois detalhes documentados que reforçam isso: o crédito de computação não cobre réplicas de leitura nem branching, e a computação é cobrada por hora cheia iniciada, mesmo que o projeto rode por poucos minutos. Ou seja, o componente mais importante da stack, o banco, não escala a zero.

A escada de computação é o custo que aparece depois, e ela é de memória, não de armazenamento:

Fonte: página de preços e documentação de compute e disco do Supabase, leitura de 6 de agosto de 2026.

As quotas incluídas no Pro são folgadas para um MVP: 8 GB de disco por projeto, 100 GB de storage, 250 GB de egress e 100 mil usuários ativos mensais de autenticação. O excedente é previsível: US$ 0,125 por GB de disco, US$ 0,09 por GB de egress e US$ 0,00325 por usuário ativo extra.

O plano gratuito é para protótipo, não para produto no ar

Vale ser direto, porque esse erro custa caro:

• o projeto é pausado após uma semana de inatividade, exatamente o cenário do MVP que fica parado esperando a reunião com o investidor;
• não há backup automático no plano gratuito;
• o limite é de 500 MB de banco, 1 GB de storage e dois projetos ativos por organização;
• Point-in-Time Recovery é um adicional pago que custa US$ 100 por mês para sete dias de retenção, o que dobra a conta de um Pro pequeno.

A regra que usamos: protótipo e estudo podem viver no gratuito; nada com dado real de cliente nasce fora do Pro.

Vetores e busca: o que é verdade e o que é marketing

O Supabase é uma escolha tecnicamente boa para RAG, mas não pelo motivo que costuma ser vendido. O que existe de forte é a busca híbrida em SQL puro: full text search nativo do Postgres com índice GIN, combinado com pgvector usando índice HNSW, e os dois rankings fundidos por Reciprocal Ranked Fusion em uma única consulta. Isso substitui uma arquitetura de Postgres mais banco vetorial mais motor de busca por um banco só.

O que não existe é embedding gerenciado. A geração automática de embeddings no Supabase é uma receita de implementação, montada com gatilho, fila, agendador e uma função de borda, não um recurso pronto. Quem prometer "RAG automático" está vendendo documentação como produto.

Resend: contratado por experiência, não por preço

O terceiro componente é o mais fácil de escolher e o mais fácil de justificar errado. O Resend tem o melhor conjunto de ferramentas para desenvolvedor da categoria, com integração simples em stacks modernas, e o plano gratuito cobre 3.000 e-mails por mês com teto de 100 por dia.

O que ele não é: o mais barato. O Amazon SES entrega mil e-mails por cerca de US$ 0,10, e a diferença em volume é de uma ordem de grandeza. O comparativo completo, com as franquias gratuitas que sobraram em 2026 e o piso de preço por faixa de volume, está em e-mail transacional: os provedores grátis e os mais baratos.

Duas armadilhas do plano gratuito merecem atenção: o teto é de 100 e-mails por dia, e não apenas 3.000 por mês, então um disparo de onboarding em lote bate no limite diário antes do mensal. E cada endereço em destinatário, cópia e cópia oculta conta separadamente.

A decisão honesta é essa: no início, o custo de e-mail é irrelevante e o tempo de integração não é. Um MVP que envia 2.000 e-mails por mês paga zero em qualquer provedor da lista, e a hora de engenharia economizada vale mais que a diferença de centavos. Quando o volume subir, trocar de provedor de e-mail é das migrações mais baratas que existem, porque a superfície de integração é pequena.

Simulação de custo: um SaaS B2B real

Cenário: produto B2B com 300 empresas clientes, cerca de 2.000 usuários ativos por mês, 1,5 milhão de requisições mensais, 6 GB de banco, 40 GB de arquivos e 15 mil e-mails transacionais por mês. Ambientes de produção e homologação.

Preços oficiais lidos em 6 de agosto de 2026. Converta pelo câmbio do dia antes de aprovar orçamento.

Trocando o Resend pelo Amazon SES, o total cai para cerca de US$ 47. Trocando a homologação por um projeto no plano gratuito, que aceita ser pausado, cai para cerca de US$ 37. E o mesmo produto rodando em um cluster gerenciado começaria em US$ 73 apenas de control plane, sem nodes, sem banco e sem balanceador.

A diferença de dinheiro é relevante. A diferença de tempo é maior: essa stack sobe no ar no primeiro dia, e a outra consome uma semana de configuração que o produto ainda não precisava pagar.

Onde serverless quebra

Nenhuma dessas plataformas é neutra em relação ao formato da sua aplicação. Existem cargas que simplesmente não encaixam, e conhecê-las antes evita descobrir tarde.

1. Processamento longo, funções de borda do Supabase têm teto de 400 segundos de tempo total nos planos pagos e apenas 2 segundos de CPU por requisição. Processar planilha grande, gerar relatório pesado ou rodar importação não é caso de uso.
2. CPU intensiva no plano gratuito, os 10 ms de CPU por invocação do Workers Free inviabilizam renderização pesada no servidor e criptografia. O plano pago resolve, o gratuito não.
3. Fan-out de chamadas externas, um Worker aceita no máximo seis conexões simultâneas aguardando resposta por invocação. Uma rota que consulta oito APIs em paralelo precisa ser reescrita em lotes.
4. Escrita concorrente pesada, cada banco D1 é single-threaded e processa consultas em sequência: uma consulta de 100 ms limita o banco a cerca de dez por segundo. Pior, o D1 cobra linhas escaneadas, não linhas retornadas: uma consulta sem índice em uma tabela de 5 mil linhas conta 5 mil leituras, ainda que devolva dez. Uma tela de listagem mal indexada consome a franquia diária sozinha. Para o domínio do produto, o Postgres do Supabase é o lugar certo; o D1 serve a dados de borda e leitura simples.
5. Conexões persistentes, websocket de longa duração, fila própria e worker que fica vivo esperando trabalho pedem outra arquitetura, seja Durable Objects, seja um container.
6. Bibliotecas que dependem do Node completo, o Workers implementa um subconjunto do Node. Módulos como http2, vm, cluster e domain existem apenas como stubs, e qualquer dependência que precise de sistema de arquivos real ou de processos filhos não roda.

Os tetos de execução, lado a lado

O limite de tempo é o que decide se um processo cabe ou não na plataforma. Vale ter a tabela à mão antes de prometer funcionalidade ao cliente.

Fonte: documentação oficial de cada plataforma, leitura de 6 de agosto de 2026.

Duas leituras práticas. A primeira: se o seu processo mais longo passa de 15 minutos, a única plataforma da lista que resolve sem sair para máquina é o Cloud Run em modo job. A segunda: o payload máximo derruba upload de arquivo grande passando pela função em quase todas elas, então o padrão correto é o cliente enviar direto para o storage com URL assinada.

Sobre cold start, vale honestidade: não existe medição independente e reproduzível publicada que sustente as tabelas de milissegundos que circulam. O que dá para afirmar é o que as próprias empresas escrevem: a Cloudflare diz que um isolate carrega em menos de 5 ms e que ela pré-aquece o Worker durante o handshake TLS, e a AWS descreve o SnapStart como redução para menos de um segundo em cenários ótimos, não como eliminação do problema. A própria AWS registra que cold starts costumam ocorrer em menos de 1% das invocações, o que ajuda a calibrar o tamanho real da preocupação.

A pegadinha número um: connection pooling

Esse é o incidente mais comum de time que sobe MVP serverless, e ele tem solução documentada. Ambiente serverless abre muitas conexões curtas, e uma instância Micro do Supabase suporta apenas 60 conexões diretas, contra 200 pelo pooler.

A regra é curta: a aplicação usa o pooler em modo transaction na porta 6543, e as migrações usam a conexão direta na 5432. O modo transaction não suporta prepared statements, e é isso que quebra quando alguém esquece o parâmetro.

# Aplicacao serverless: pooler em modo transaction
DATABASE_URL="postgresql://...@...:6543/postgres?pgbouncer=true"

# Migracoes e ferramentas de schema: conexao direta
DIRECT_URL="postgresql://...@...:5432/postgres"

Com Drizzle, o equivalente é passar prepare: false ao cliente. Apontar a aplicação para a 5432 derruba o banco por esgotamento de conexão; apontar para a 6543 sem desligar prepared statements quebra em produção com erro difícil de ler.

Egress e residência de dados: a conta muda no Brasil

Esse é o ponto que quase nenhum comparativo internacional cobre e que muda a decisão de quem atende cliente brasileiro. Hospedar no Brasil por exigência de residência de dados custa consideravelmente mais em transferência de saída.

Fonte: AWS Price List API, oferta AWSDataTransfer, publicação de 20 de julho de 2026, consultada em 6 de agosto de 2026; anúncio oficial de preços de rede do Google Cloud; página de preços da Vercel. As tabelas em HTML da AWS são renderizadas por JavaScript e não expõem essas faixas, por isso a fonte correta é a API de preços, não a página de marketing.

Na AWS, a primeira faixa em São Paulo custa cerca de 67% a mais que em Norte-Virgínia. A Vercel cobra ainda separadamente o transporte da CDN até a função, que na região de São Paulo sai a US$ 0,41 por GB sem franquia, então comparações do tipo "é X vezes mais caro" precisam dizer o que está sendo medido.

E vale saber que existe uma porta de saída documentada: desde março de 2024 a AWS isenta a taxa de transferência para clientes que estão migrando para fora, mediante solicitação e aprovação por conta, com prazo de 90 dias para concluir. Não é automático, mas existe.

O que a lei exige, na prática

Residência de dados no Brasil costuma ser tratada como obrigação legal absoluta, e não é isso que a LGPD diz. O artigo 33 permite transferência internacional em nove hipóteses, e a Resolução CD/ANPD nº 19, de 23 de agosto de 2024, regulamentou os mecanismos: decisão de adequação, cláusulas-padrão contratuais, cláusulas equivalentes, cláusulas específicas e normas corporativas globais. As cláusulas-padrão devem ser adotadas sem modificação, e o período de adequação dos contratos já se encerrou.

O detalhe que muda a escolha de fornecedor: até agosto de 2026, a única decisão de adequação emitida pela ANPD reconhece a União Europeia, pela Resolução nº 32, de janeiro de 2026, cobrindo 30 jurisdições. Os Estados Unidos não têm decisão de adequação brasileira, o que significa que usar fornecedor com dados em solo americano exige apoiar a transferência em cláusulas-padrão contratuais, não em adequação.

Ou seja: hospedar fora do Brasil continua legal e comum, desde que o contrato com o fornecedor carregue o instrumento certo. A pergunta para o jurídico não é "onde ficam os dados", é "qual mecanismo do artigo 33 sustenta essa transferência".

Lock-in: o que é reversível e o que não é

Aqui está a parte que costuma ser tratada como slogan ("é open source, é só migrar") e merece precisão. O aprisionamento nessa stack não é uniforme, ele tem três camadas.

Três observações que mudam a leitura:

RLS é Postgres puro. As políticas de segurança em nível de linha não são um recurso da plataforma, são do banco. Elas viajam no dump. Esse é o argumento mais forte a favor da escolha: a parte mais valiosa do sistema, o modelo de dados com suas regras de acesso, é padrão.

O runtime da borda é aberto. O motor que executa os Workers é publicado sob licença Apache 2.0 e roda fora da Cloudflare, e o conceito de data de compatibilidade permite travar a versão da API durante uma migração. O código do Worker é portável; o que prende são os serviços de estado.

A documentação de saída é assimétrica, e isso diz muito. Existe farta documentação oficial para entrar nessas plataformas e quase nenhuma para sair. A Supabase documenta migrar para a Supabase e migrar da nuvem dela para o self-hosted dela, mas não para um Postgres gerenciado de terceiros. Quem publica o guia de saída do Supabase é uma concorrente, e esse guia cobre apenas o schema principal, sem tratar de autenticação, storage, realtime, extensões ou políticas de acesso.

O pg_dump é a parte fácil da migração. O que trava é tudo aquilo que não é tabela.

Vale ainda um cuidado com a palavra "open source", porque ela não significa a mesma coisa em todos os concorrentes: o Supabase é Apache 2.0 e o PocketBase é MIT, ambos permissivos de verdade, enquanto alguns concorrentes usam licenças que proíbem competir com o produto e só se convertem em licença aberta no futuro. E a versão auto-hospedada do Supabase roda apenas um projeto e não inclui branching, métricas avançadas, backups gerenciados, recuperação a ponto no tempo nem a API de gerenciamento. "É só auto-hospedar" transfere para o seu time exatamente aquilo pelo qual você estava pagando.

O contrapeso: quem saiu da nuvem e o que isso realmente prova

Três casos são citados em toda discussão de serverless, quase sempre com a conclusão errada. Vale colocar cada um no seu tamanho.

A 37signals reduziu o gasto anual de nuvem de US$ 3,2 milhões para US$ 1,3 milhão, com cerca de US$ 700 mil investidos em hardware próprio, e projeta economia na casa de US$ 10 milhões em cinco anos. É o caso mais bem documentado que existe. Também é o caso de uma empresa com produtos maduros, carga previsível e time de infraestrutura próprio. Nada disso descreve um MVP.

O Prime Video publicou que, ao empacotar em um único processo um serviço antes distribuído em funções e orquestração, o custo de infraestrutura caiu mais de 90%. O texto foi despublicado e o escopo real era uma ferramenta interna de análise de qualidade de vídeo de um time, que o próprio post dizia não ter sido projetada para rodar em grande escala. Não é, e nunca foi, "a Amazon abandonou serverless".

A Ahrefs comparou servidor próprio em colocation com instância equivalente na nuvem e chegou a uma razão de mais de dez vezes. O próprio autor registrou que a comparação não é exata e que se trata de uma carga extremamente intensiva em CPU e disco, um rastreador de web em escala, que é o oposto de uma aplicação orientada a eventos.

O padrão dos três é o mesmo: carga alta, estável e previsível vence com infraestrutura própria; carga baixa, intermitente e incerta vence com uso medido. Um MVP é, por definição, o segundo caso. Citar a 37signals para justificar Kubernetes em um produto sem usuários é usar a evidência ao contrário.

Quando não começar serverless

Os casos que pedem outra decisão desde o primeiro dia são específicos e reconhecíveis:

• Exigência contratual de residência de dados ou de SLA de uptime. Nenhum plano abaixo do Enterprise do Supabase oferece SLA contratual de disponibilidade, nem o de US$ 599 por mês, que garante apenas tempo de resposta de suporte. Se o contrato do seu cliente exige SLA, isso muda a conversa antes de qualquer outra coisa.
• Processamento pesado e contínuo. Transcodificação, treinamento, uso de GPU e jobs longos não pertencem à borda.
• Carga estável 24 horas por dia. O modelo de cobrança por uso vence no tráfego intermitente e perde no tráfego constante, onde instância reservada é mais barata.
• Dependência de biblioteca incompatível com o runtime. Se o núcleo do produto depende de algo que só roda em Node completo ou em processo nativo, o container é o lugar.

Os gatilhos objetivos de migração

"Migrar quando crescer" não é critério. Estes são:

• A instância de banco passou de Large e o gargalo é CPU, não consulta mal escrita
• Existe processo de negócio que não cabe no tempo máximo de execução da plataforma
• O custo de computação por uso ultrapassou o custo equivalente reservado por três meses seguidos
• Um contrato passou a exigir SLA de disponibilidade ou residência de dados em região específica
• O time já opera mais de cinco serviços independentes e precisa de padrão único de deploy

Se nenhum foi marcado, migrar agora é resolver um problema que ainda não existe, e é exatamente esse trabalho que o MVP não pode pagar. Quando algum for marcado, a saída não precisa ser total: dá para mover só o componente que estourou, mantendo o resto onde está. Postgres continua sendo Postgres em qualquer lugar, e é isso que torna a decisão reversível.

Quer subir um MVP sem escolher errado a infraestrutura?

A X-Apps desenha a arquitetura, escolhe a stack pelo estágio real do produto e entrega com deploy, ambientes e caminho de evolução já definidos.

---

Nome

Sobrenome

Telefone

AfghanistanÅland IslandsAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntigua and BarbudaArgentinaArmeniaArubaAscension IslandAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBonaire, Sint Eustatius and SabaBosnia and HerzegovinaBotswanaBrazilBritish Indian Ocean TerritoryBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaChristmas IslandCocos (Keeling) IslandsColombiaComorosCongoCongo, Democratic Republic of theCook IslandsCosta RicaCote d'IvoireCroatiaCubaCuraçaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFalkland IslandsFaroe IslandsFederated States of MicronesiaFijiFinlandFranceFrench GuianaFrench PolynesiaGabonGambiaGeorgiaGermanyGhanaGibraltarGreeceGreenlandGrenadaGuadeloupeGuamGuatemalaGuernseyGuineaGuinea-BissauGuyanaHaitiHoly See (Vatican City State)HondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsle of ManIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKosovoKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacaoMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMoldovaMonacoMongoliaMontenegroMontserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorth KoreaNorth MacedoniaNorthern Mariana IslandsNorwayOmanPakistanPalauPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarReunionRomaniaRussiaRwandaSaint BarthélemySaint HelenaSaint Kitts and NevisSaint LuciaSaint Martin (French Part)Saint Pierre and MiquelonSaint Vincent and the GrenadinesSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint MaartenSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSouth KoreaSouth SudanSpainSri LankaSudanSurinameSvalbard and Jan MayenSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTimor-LesteTogoTokelauTongaTrinidad and TobagoTristan da CunhaTunisiaTurkeyTurkmenistanTurks and Caicos IslandsTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.Wallis and FutunaWestern SaharaYemenZambiaZimbabwe

Email

Enviar

Checklist antes de escolher a stack do seu MVP

• O produto tem processo que precisa rodar mais de 400 segundos?
• Existe exigência contratual de SLA ou de região específica de dados?
• O front-end depende de conexão persistente com o servidor?
• Alguma biblioteca essencial exige Node completo ou processo nativo?
• Vai existir dado real de cliente antes da primeira venda? Se sim, plano pago desde já.
• O ambiente de homologação está previsto no orçamento? Ele custa por fora.
• O acesso ao banco já está configurado com pooler em modo transaction?

Se as quatro primeiras respostas forem não, a stack deste artigo entrega mais velocidade de validação por menos dinheiro do que qualquer alternativa com servidor.

Perguntas frequentes

Conclusão

A pergunta de 2026 não é se serverless substitui servidores. É quanto tempo o seu produto pode passar sem precisar deles, e a resposta honesta é: bem mais do que a maioria dos times imagina. Uma aplicação B2B com alguns milhares de usuários cabe com folga na stack descrita aqui, por algumas dezenas de dólares por mês.

O erro caro não é escolher serverless. É escolher a infraestrutura pela escala que você espera ter em três anos, pagando hoje por uma complexidade que atrasa a única coisa que importa nesse estágio: descobrir se alguém quer o produto.

Comece simples, meça, e resolva problemas de escala quando eles aparecerem de verdade, com o dinheiro que a validação trouxe.

Referências

• Cloudflare Workers: limites e preços
• Cloudflare R2: preços e política de egress
• Amazon S3: preços de armazenamento e transferência
• Supabase: preços e computação e disco
• Supabase: pausa de projetos no plano gratuito
• Supabase: busca híbrida e índices de vetores
• Supabase: conexão com Postgres e pooling
• Amazon EKS: preços e Google GKE: preços
• AWS Lambda: cotas e limites e Google Cloud Run: limites
• AWS: isenção de taxa de transferência para quem migra para fora
• ANPD: transferência internacional de dados e cláusulas-padrão contratuais
• 37signals: a série sobre saída da nuvem

Todos os preços e limites foram lidos nas páginas oficiais em 6 de agosto de 2026, em dólar americano. Preços de nuvem mudam sem aviso e variam por região: confirme na fonte antes de fechar orçamento.