Django vs FastAPI no Cloudflare Workers: qual escolher?

Django vs FastAPI no Cloudflare Workers: qual escolher?

Escolha Django se você já tem uma aplicação Django ou precisa de um backend completo para o produto. Escolha FastAPI se vai criar do zero uma API tipada, um serviço de webhooks ou um endpoint de borda com muita E/S. Mantenha a aplicação na origem atual se algum pacote obrigatório, modelo de processo ou carga com estado não for compatível com o runtime do Workers.

O Cloudflare mudou o ponto de partida em 2 de setembro de 2026. Agora, o Python Workers pode hospedar aplicações WSGI e ASGI diretamente por meio de adaptadores do módulo workers. WSGI é o contrato web síncrono tradicional do Python. ASGI é seu sucessor assíncrono, criado para operações de E/S simultâneas, streaming e conexões de longa duração. Os exemplos publicados pelo Cloudflare associam explicitamente Django a WSGI e FastAPI a ASGI, embora Django possa usar os dois protocolos.

Django é a opção mais segura para migrar quando a estrutura integrada do produto já gera valor para o negócio. O Cloudflare agora documenta pontos de entrada WSGI e ASGI, além de um caminho com django-cf para D1 e Durable Objects.

FastAPI é a escolha mais direta para um projeto novo quando a entrega é uma API, e não um produto web apoiado por um painel administrativo. O Cloudflare fornece a camada de servidor ASGI, então o Worker não precisa executar Uvicorn nem gerenciar um socket.

O preço empata até o consumo de CPU se distanciar

Nenhum dos frameworks tem vantagem de preço. Os valores foram verificados em 5 de setembro de 2026 nas páginas oficiais disponíveis: Django é gratuito e de código aberto sob a licença BSD, FastAPI usa a licença MIT e o Workers Paid começa em $5 por conta por mês.

Esses $5 incluem 10 milhões de requisições e 30 milhões de milissegundos de CPU por mês. Cada milhão adicional de requisições custa $0.30, e cada milhão extra de milissegundos de CPU custa $0.02. As requisições de Static Assets são gratuitas e ilimitadas. O Workers Free inclui 100,000 requisições por dia, mas o limite de 10 ms de CPU por invocação é uma referência ruim para comparar aplicações de framework que não sejam triviais.

Normalize os dois frameworks para a mesma carga e o resultado é, de propósito, pouco empolgante. Com 15 milhões de requisições dinâmicas por mês e média de 7 ms de CPU por requisição, qualquer um deles custa $8 por mês: $5 de base, $1.50 pelo excedente de requisições e $1.50 pelo excedente de CPU. Com 100 milhões de requisições e a mesma média de 7 ms, qualquer um custa $45.40 por mês.

O cálculo de sensibilidade é mais útil do que um benchmark inventado entre frameworks. Depois que as duas aplicações esgotam a franquia de CPU, cada diferença média de 1 ms altera a fatura em $0.30 para 15 milhões de requisições e em $2 para 100 milhões. Portanto, uma diferença medida de 5 ms representa $1.50 ou $10 por mês nesses volumes. É pouco demais para justificar a reescrita de um framework apenas pelo preço de computação.

Não existe um ponto de virada no preço cobrado pelo provedor. Uma opção só fica mais barata quando há diferença no tempo de CPU medido, nos serviços de apoio ou no custo de manutenção. Um framework rápido cercado por chamadas lentas ao banco de dados não salva a arquitetura. Da mesma forma, um framework integrado que elimina semanas de trabalho de substituição pode ser o sistema mais barato, ainda que o outro vença em um microbenchmark.

Migração: Django vence nos sistemas existentes; FastAPI, nas novas APIs

A mudança no adaptador é pequena; a migração da aplicação, não. Os dois frameworks exigem apenas um ponto de entrada enxuto, mas tudo o que existe atrás dele ainda precisa se adaptar ao modelo de pacotes, armazenamento, sistema de arquivos e ciclo de vida do Cloudflare.

Migração de Django para Cloudflare Workers: o adaptador é a parte fácil

Django pode manter seu objeto de aplicação WSGI padrão e entregá-lo ao adaptador do Cloudflare:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

Isso basta para converter uma requisição recebida pelo Workers em uma chamada WSGI do Django. Não migra o banco de dados, os arquivos persistentes, as tarefas agendadas, a estratégia de sessão nem todos os pacotes de terceiros do Django.

O novo guia do pacote Django do Cloudflare oferece ao framework um caminho de armazenamento realmente nativo. O pacote django-cf fornece backends compatíveis com SQLite para D1 e Durable Objects. Ambos operam o ORM síncrono do Django, por isso o Cloudflare orienta servir essa configuração via WSGI. Em um produto CRUD que já depende de modelos, formulários, autenticação e admin, preservar essas camadas pode poupar muito mais trabalho do que uma troca de framework economizaria em runtime.

O obstáculo aparece quando o sistema existente parte das premissas de um servidor convencional. Um driver de banco de dados pode depender de um wheel nativo que o Workers não consegue carregar. Uploads de usuários não podem permanecer no sistema de arquivos do isolate. Um agendador local do processo ou um pool de threads não pode simplesmente ser levado para lá. O suporte a Django significa que o protocolo de requisição funciona; não é uma certificação de toda a aplicação instalada.

Migração de FastAPI para Cloudflare Workers: ideal para um serviço enxuto

O adaptador direto do FastAPI é menor porque o framework já se comunica por ASGI:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

O Cloudflare assume o papel de servidor ASGI normalmente desempenhado pelo Uvicorn. FastAPI preserva as declarações de rotas, a validação com Pydantic, a injeção de dependências e a documentação OpenAPI gerada. Assim, um novo receptor de webhooks, uma API JSON tipada ou um serviço apoiado por bindings começa com menos componentes de aplicação do que Django.

Em troca, há mais trabalho de montagem. FastAPI deliberadamente não determina o banco de dados nem o modelo de dados. Também não inclui o admin de conteúdo do Django. Você escolhe essas peças, verifica cada pacote no ambiente do Workers e assume a integração. Isso é uma vantagem para um serviço focado e um custo para um produto cujos operadores precisam de back office desde o primeiro dia.

Vencedor em migração: Django para uma aplicação que já usa Django; FastAPI para uma nova API. Reescrever em FastAPI um sistema Django que funciona, só porque agora os dois rodam na borda, é escolher o projeto errado.

WSGI vs ASGI no Cloudflare: FastAPI vence em concorrência, Django preserva a escolha

ASGI é o modelo de requisição mais forte para um novo serviço com muita E/S, mas WSGI é o caminho documentado para integrar o ORM do Django ao Cloudflare. A escolha do protocolo deve seguir a carga de trabalho, não a afirmação genérica de que assíncrono é sempre mais rápido.

WSGI apresenta a aplicação como uma função síncrona. O adaptador WSGI atual do Cloudflare executa essa função dentro do handler assíncrono fetch do Worker, converte o corpo da requisição vindo de um ReadableStream JavaScript e transmite ao cliente o iterável de resposta da aplicação. É um caminho de compatibilidade para aplicações síncronas maduras, não um segundo servidor web rodando dentro do isolate.

ASGI permite que a aplicação aguarde operações de rede e armazenamento sem prender o fluxo da requisição a uma chamada síncrona. O adaptador do Cloudflare também converte eventos de WebSocket do ASGI em WebSockets do Workers. FastAPI foi criado sobre esse modelo. Django também pode usá-lo; portanto, “Django” e “WSGI” não são sinônimos.

A escolha do armazenamento pode inverter a decisão de protocolo. Segundo o Cloudflare, seus backends de D1 e Durable Objects para Django operam o ORM síncrono e devem ser servidos via WSGI. Se o motivo para escolher Django é seu ORM, seguir esse caminho WSGI documentado faz mais sentido do que impor o rótulo ASGI a uma camada de dados síncrona.

No FastAPI, o modelo assíncrono só ajuda quando as esperas podem se sobrepor. Um endpoint que passa a maior parte do tempo em validação serial ou em processamento pesado de Python continua consumindo CPU. Já um endpoint que aguarda várias operações independentes de HTTP ou de bindings do Cloudflare tem um motivo mais claro para usar ASGI.

Inicialização: a surpresa do lifespan no FastAPI

No Workers, Django sobre WSGI tem hoje o modelo de inicialização mais previsível. FastAPI continua funcionando, mas seus hooks de lifespan não se comportam como em um processo Uvicorn de longa duração.

O Cloudflare reduz o trabalho de cold start do Python com snapshots de implantação. Durante a implantação, a plataforma cria um isolate V8, injeta o Pyodide, executa o módulo de entrada do Worker e seus imports no escopo global e, depois, captura um snapshot da memória WebAssembly. Uma requisição pode carregar esse snapshot em vez de reconstruir o ambiente Python do zero. Ainda assim, o código em escopo global precisa ser analisado e executado dentro do limite de inicialização de 1 segundo da plataforma. O Cloudflare documenta esse ciclo de vida diretamente.

O contrato normal de lifespan do FastAPI segue o formato de um processo: o código de startup roda uma vez antes de a aplicação aceitar requisições, e o código de shutdown roda uma vez depois que ela termina. O código-fonte do adaptador ASGI atual do Cloudflare faz algo consideravelmente diferente. Sua função fetch inicia a aplicação ASGI, envia um evento de startup do lifespan, atende uma requisição e, em seguida, envia o shutdown. O comentário no código descreve um ciclo de startup e shutdown antes e depois da requisição.

No adaptador atual, isso faz o código de lifespan rodar no escopo da requisição. O carregamento de um modelo, a criação de um pool de conexões, o aquecimento do schema ou a busca de uma configuração remota dentro desse ciclo podem se repetir, em vez de ter o custo diluído pelo isolate. Isso não é motivo para descartar FastAPI. É motivo para manter o trabalho de lifespan barato e idempotente e transferir a inicialização determinística e segura para código que possa aproveitar o snapshot de implantação do Cloudflare.

A aplicação WSGI do Django é criada no escopo do módulo no exemplo do Cloudflare e não passa pelo ciclo de lifespan do ASGI. Sua inicialização, portanto, faz parte do caminho de startup global, no qual o teto de 1 segundo é a restrição. Se você escolher o ponto de entrada ASGI do Django e usar componentes dependentes de lifespan, examine-os sob o mesmo comportamento do adaptador.

Frameworks Python no Workers enfrentam a mesma barreira de pacotes

Há empate nesta categoria, e ela pode eliminar os dois frameworks. Django e FastAPI rodam no mesmo ambiente Pyodide dentro do V8, então nenhum deles escapa dos limites de pacotes, memória, sistema de arquivos ou inicialização.

A documentação de pacotes do Cloudflare informa que pywrangler empacota as dependências declaradas em pyproject.toml. As fontes compatíveis incluem pacotes pure Python e PyEmscripten do PyPI, além dos pacotes distribuídos com Pyodide. PyEmscripten é o formato de wheel voltado para WebAssembly. O Cloudflare ainda descreve esse ecossistema como inicial, e alguns pacotes não têm wheel compatível.

As verificações decisivas da plataforma são objetivas:

• O bundle descompactado do Worker não pode ultrapassar 64 MiB nos planos Free ou Paid.
• Cada isolate tem 128 MB de memória.
• A inicialização no escopo global precisa terminar em até 1 segundo.
• O sistema de arquivos do Python é efêmero e privado para cada isolate.
• threading e multiprocessing podem ser importados, mas não funcionam na VM WebAssembly.

A limitação do sistema de arquivos inviabiliza mais migrações do que a assinatura do adaptador faz parecer. Arquivos temporários são aceitáveis. Uploads persistentes, relatórios gerados, arquivos SQLite usados como estado durável e caches compartilhados em disco não são. Armazene objetos duráveis em D1, Durable Objects, KV ou R2 de acordo com o padrão de acesso, não em um diretório que desaparece junto com o isolate. Os limites exatos estão no guia da biblioteca padrão do Python do Cloudflare.

A compatibilidade de pacotes é uma condição binária que vem antes de qualquer discussão sobre desempenho. Monte o grafo de dependências real, não um subconjunto de hello world. Conseguir importar um pacote no CPython para desktop não prova nada sobre a disponibilidade das extensões nativas dele no Pyodide.

Adequação operacional: Django vence em produtos; FastAPI, em serviços

Django vence quando a unidade de trabalho é um produto; FastAPI vence quando é um serviço. Essa distinção é mais duradoura do que o throughput dos frameworks em uma rota sintética.

Melhor para um produto com painel administrativo: Django

Django reúne autenticação de usuários, administração de conteúdo, ORM, templates, middleware e outros recursos comuns a produtos web. Sua visão geral oficial destaca explicitamente a autenticação e a administração de conteúdo. Quando uma pequena equipe de operações precisa gerenciar clientes, pedidos, permissões e registros editoriais, o admin integrado pode valer mais do que reduzir alguns milissegundos do overhead do framework.

No Workers, django-cf oferece a esse modelo integrado um caminho para D1 ou Durable Objects. O custo é um acoplamento maior a um ORM síncrono e uma superfície de framework mais ampla para acomodar nos limites do runtime.

Melhor para um serviço de API tipada: FastAPI

FastAPI se apoia em OpenAPI, JSON Schema, validação com Pydantic e injeção de dependências. Sua documentação de recursos também deixa clara a contrapartida: a escolha do banco de dados e do modelo de dados permanece em aberto. É o formato certo para um gateway de API, um receptor de webhooks, um endpoint de modelo ou um pequeno serviço que se comunica com bindings e APIs remotas.

A ausência de admin e ORM integrados não é um defeito quando o serviço não precisa deles. Ela se transforma em custo de entrega assim que uma pessoa sem perfil técnico precisa de um back office.

Melhor em velocidade bruta: ainda não comprovado no Workers

A suíte independente da TechEmpower historicamente colocou FastAPI sob Uvicorn entre os frameworks Python mais rápidos, segundo a página de benchmarks do FastAPI. A TechEmpower mediu cargas padronizadas de JSON, banco de dados, ORM, templates e outras categorias relacionadas. Ela não mediu os adaptadores Pyodide do Cloudflare, e o projeto foi encerrado em 24 de março de 2026. Esses resultados são um sinal histórico atribuído, não uma previsão para implantação no Workers.

O Cloudflare não publicou um benchmark de Django contra FastAPI usando esses adaptadores. Portanto, a velocidade bruta no Workers continua sem comprovação até que uma rota representativa inclua validação, bindings, chamadas ao banco de dados, formato da resposta, comportamento de inicialização e métricas de CPU do Workers.

Quanto custa trocar — e quem não deveria fazer isso

Não troque de framework apenas para obter suporte do Cloudflare. Os dois agora têm esse suporte. Só faça a mudança quando o framework de destino eliminar mais trabalho de aplicação do que a migração criar.

Reescrever Django em FastAPI implica substituir ou separar models, migrations, telas de admin, fluxos de autenticação, middleware, templates e qualquer pacote que espere o ciclo de requisição do Django. O resultado pode ser excelente para uma API enxuta, mas não é uma configuração de implantação. Se admin e ORM são muito usados, a troca destrói a vantagem existente antes de criar uma nova.

Migrar FastAPI para Django só faz sentido quando o produto deixou de caber em uma arquitetura de serviço e precisa da estrutura operacional integrada do Django. Fora desse cenário, a mudança adiciona convenções e componentes desnecessários para uma API pequena.

FastAPI pode montar uma aplicação Django WSGI em um caminho por meio de a2wsgi.WSGIMiddleware. Isso pode viabilizar uma decomposição gradual em servidores convencionais. No Workers, a abordagem acrescenta outro pacote e mais uma fronteira de protocolo, enquanto os guias iniciais do Cloudflare documentam cada framework separadamente. Trate um Worker combinado como uma integração personalizada a ser comprovada, não como o atalho padrão.

Em qualquer direção, inclua estas frentes no custo da migração:

• Dados: compatibilidade do schema, migrations, comportamento das transações e mudança para D1, Durable Objects ou outro armazenamento acessível.
• Arquivos: ativos estáticos podem usar Workers Static Assets, enquanto mídias persistentes dos usuários precisam de armazenamento de objetos durável, como R2.
• Trabalho em segundo plano: substitua agendadores locais do processo, pools de threads e processos filhos por trabalho assíncrono nativo da plataforma.
• Dependências: resolva o lockfile completo no Python Workers e, depois, confira o bundle de 64 MiB e o resultado da inicialização em 1 segundo.
• Operações: reconstrua logs, alertas de erro, rollback de implantação, secrets e uma linha de base de desempenho por rota.

Quem não deveria trocar? Um monólito Django estável, com banco de dados funcional e um fluxo administrativo relevante, não deveria virar FastAPI por moda. Um serviço FastAPI que depende de wheels nativos indisponíveis não deveria migrar para Workers só porque agora existe uma página de documentação para o framework. Uma equipe cuja latência é dominada por um banco de dados distante deveria corrigir a localização dos dados antes de trocar o framework de requisição.

O que fazer na segunda-feira

Na próxima semana, valide uma rota representativa — não a aplicação inteira. Escolha a rota que reproduz as características de pacotes, estado e latência do sistema em produção e use-a para eliminar rapidamente as opções erradas.

FAQ sobre Django e FastAPI no Cloudflare Workers