Análise do Django: ainda vale a pena?

O Django lançou duas versões de funcionalidades e reescreveu toda a sua cadência de lançamentos nos oito meses entre dezembro de 2025 e agosto de 2026.

Tudo isso aconteceu a um framework cuja reputação pouco mudou desde 2023: o framework Python com tudo incluído, produtivo, opinativo, apenas síncrono e a perder terreno para o FastAPI. O rótulo de "apenas síncrono" está ultrapassado, e a história da popularidade é mais complicada do que sugerem os números das manchetes.

É aqui, então, que eu chego quanto a saber se o Django ainda vale a pena na 6.1: um veredicto com nota, os tipos de projeto a que serve e aqueles em que o FastAPI é hoje a melhor escolha.

A versão curta

Sim, com condições. O Django 6.1 continua a ser a escolha padrão mais forte quando o admin, a autenticação, os formulários e o ORM são a maior parte do trabalho, e a distância no assíncrono encurtou o suficiente para que "apenas síncrono" já não seja motivo para o excluir. É errado para uma única API de alta concorrência sem superfície de administração. 4 em 5.

• O que se compra é o conjunto. O ORM, as migrações, a autenticação por sessão com permissões, uma camada de formulários e um admin gerado chegam juntos e já integrados, e não como cinco bibliotecas mais as costuras entre elas.
• Os trabalhos em segundo plano são o eixo fraco. O framework Tasks do Django 6.0 dá-lhe um decorador e uma chamada para pôr em fila, mas nenhum worker, pelo que o Celery ou equivalente continua a ser uma decisão sua.
• O assíncrono está muito melhor e claramente por acabar. O Django suporta views assíncronas e chamadas assíncronas ao ORM, mas as transações não funcionam em modo assíncrono. Sob WSGI, as views assíncronas ainda conseguem executar E/S assíncrona concorrente dentro de um pedido, mas não se obtêm os benefícios de uma pilha de pedidos totalmente assíncrona; pedidos de longa duração e alta concorrência de ligações exigem ASGI.
• Planear para lá de 2027 ficou mais fácil. A partir de janeiro de 2028, o Django lança uma versão de funcionalidades por ano, cada uma com três anos de suporte, e o rótulo "LTS" desaparece porque agora todas as versões recebem esse compromisso.
• Certo para produtos com muito admin e muito CRUD e para equipas pequenas. Errado para uma única API de alto débito ou de streaming, sem admin nem formulários, onde o FastAPI é a escolha mais natural.

Como construí esta análise: Esta é uma avaliação do Django 6.1 construída a partir das notas de lançamento e da documentação do próprio projeto, do anúncio de governação da Django Software Foundation de agosto de 2026, dos inquéritos a programadores da JetBrains/PSF de 2024 e do Django de 2025, e de profissionais identificados pelo nome que escrevem publicamente sobre a sua própria experiência em produção. Não fiz um ensaio em produção de várias semanas para este texto, e aqui não há benchmarks: nada foi testado sob carga. O Django é gratuito e tem licença BSD, e eu não tenho qualquer relação com o projeto.

O que mudou realmente no Django desde 2025?

O Django 6.0 chegou a 3 de dezembro de 2025 com um framework Tasks próprio e outras adições ao núcleo. A interface assíncrona do ORM é mais antiga: o Django 4.1 introduziu as operações assíncronas de QuerySet em 2022. O Django 6.1 tornou-se a versão estável atual a 5 de agosto de 2026. Depois, a 10 de agosto de 2026, o projeto anunciou uma versão de funcionalidades por ano a partir de janeiro de 2028, três anos de suporte para cada versão e o fim do rótulo LTS.

As notas de lançamento da 6.1 confirmam que a 6.1 suporta Python 3.12, 3.13 e 3.14, com o suporte principal a terminar em abril de 2027 e o estendido em dezembro de 2027.

Os números de versão mudam com isso. Passam a levar o ano: Django 2028, depois Django 2029 (ao menos "em que versão estás" fica mais fácil de responder). Os três anos dividem-se em um ano de correções de bugs normais seguido de dois de correções de segurança e de perda de dados, que é o que LTS significava, pelo que o rótulo desaparece.

Isso deixa uma janela desconfortável para um projeto que comece hoje. O Django 5.2 é a LTS atual, com suporte até abril de 2028. O Django 6.1 é a estável atual, mas o seu suporte estendido acaba em dezembro de 2027, cerca de quatro meses antes de a janela de suporte do Django 5.2 terminar em abril de 2028.

Portanto: procurar a janela de suporte mais longa significa começar na 5.2. Querer o framework Tasks e as funcionalidades mais recentes da linha 6.x significa começar na 6.1 e aceitar uma atualização mais cedo. Nenhuma das opções está errada, e a escolha desconfortável desaparece quando o Django 6.2 LTS chegar em abril de 2027.

Leio a mudança de cadência como um bom sinal. Os projetos em declínio esticam as suas promessas de suporte em silêncio; não as reestruturam em público com um plano datado. Este simplificou um compromisso que já estava a cumprir.

O que o Django ainda faz melhor do que qualquer outra coisa

Comece um projeto Django 6.1 e já tem autenticação por sessão a funcionar com um sistema de permissões, uma camada de formulários que valida e renderiza, um sistema de migrações ligado aos seus modelos, o ORM e um admin gerado, antes de escrever uma única funcionalidade. É essa a proposta toda, e é a parte do Django que não precisou de mudar.

O valor não está em essas peças existirem. Está em terem sido desenhadas umas contra as outras. As mesmas permissões de modelo alimentam o admin, e uma alteração num modelo gera a migração e atualiza o formulário do admin no mesmo gesto.

Montar uma cobertura equivalente a partir de bibliotecas independentes acaba por lá chegar. Também lhe dá uma superfície de manutenção permanente em cada costura, e é nas costuras que vivem os bugs.

O admin é uma ferramenta para funcionários internos. A referência do admin diz que o seu uso recomendado se limita a ser a ferramenta de gestão interna de uma organização e que não se destina a que se construa todo o seu front end à volta dela. As permissões de modelo controlam o que os utilizadores internos podem fazer depois de entrarem, e para entrar sequer é preciso is_staff. Encare isso como uma restrição, e é uma boa: recebe de graça um back office interno competente e não recebe uma interface virada para o cliente, pelo que ninguém fica tentado a lançar uma.

Os valores de segurança por omissão são a outra metade do mesmo argumento. A proteção CSRF, a parametrização de SQL através do ORM, o escape de XSS nos templates e a proteção contra clickjacking vêm ativos por omissão, em vez de serem coisas que um programador experiente tem de se lembrar de pedir na revisão. Uma equipa pequena herda escolhas feitas por gente que leu uma década de relatórios de segurança.

Depois há a idade. É lida como um passivo; eu leio-a como o argumento do ecossistema. O Django REST Framework existe e é aborrecido exatamente no sentido em que queremos que a infraestrutura seja aborrecida.

O mesmo acontece com os pacotes maduros para os problemas que surgem ao quarto mês: filtragem, limitação de pedidos, backends de armazenamento, padrões de multi-inquilino, registos de auditoria. E quando um problema é suficientemente invulgar para que nenhum pacote o cubra, há normalmente uma discussão de lista de correio com quinze anos sobre ele. Em amplitude não creio que haja mais nada em Python que se aproxime, e é esse eixo que leva alguém a escolher o Django à partida.

Onde o Django fica aquém

O Django continua sem uma tipagem nativa abrangente em todo o framework, o ritmo conservador deixa lacunas de que "tudo incluído" não o avisa, e o framework Tasks da 6.0 não tem worker. São essas as três falhas na 6.1. A lacuna da tipagem é a que o irrita diariamente; o Tasks é a que lhe muda o diagrama de arquitetura.

A maior parte da história da tipagem continua a ser montada por si com ferramentas de terceiros. django-stubs fornece stubs de tipos e um plugin de mypy próprio para o comportamento dinâmico do Django. A sua documentação atual indica suporte completo a mypy e suporte básico a pyright, pyrefly e ty. É uma situação melhor do que era, mas continua a ser uma camada de compatibilidade à parte e não uma tipagem nativa abrangente dentro do próprio Django.

Vindo de um framework construído em torno de anotações de tipos, isso é uma regressão mensurável na experiência diária no editor.

O ritmo conservador é tanto um custo como uma virtude. O Django acrescenta coisas com cuidado e tarde, e é por isso que o framework que aprendeu em 2019 é o mesmo que consegue ler hoje. É também por isso que as pilhas acabam onde acabam: não há camada WebSocket no núcleo, não há agendador, não há opinião sobre a orquestração de tarefas assíncronas. Atravesse uma dessas linhas e volta a montar as coisas por si.

O Django 6 ainda precisa de Celery?

Não especificamente o Celery. O framework Tasks do Django 6.0 normaliza a forma como uma tarefa é definida e posta em fila, mas não executa ele próprio o trabalho em fila. Em produção continua a precisar de um backend ou de um processo worker que execute as tarefas; o Celery é uma opção, não uma exigência do framework. As notas de lançamento do Django 6.0 são diretas quanto à fronteira: o Django trata da criação e do enfileiramento das tarefas, mas não fornece um mecanismo de worker, e a execução tem de ser gerida por infraestrutura externa, como um processo ou serviço à parte.

O que se obtém é a interface:

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) envia a tarefa para um backend configurado. Os dois backends que vêm com a 6.0 destinam-se a desenvolvimento e testes (ou seja, não é aquele que esperava). Agendamento, recorrência, novas tentativas e durabilidade ficam todos fora do âmbito.

Kevin Renskers, programador Django no ativo, disse-o de forma mais incisiva na sua análise do Tasks:

Em vez disso, recebemos uma abstração sem implementação.

Quanto à forma, tem razão. A intenção eu enquadraria de outra maneira. Na votação do Steering Council sobre a DEP 14, a proposta de melhoria do Django por trás da funcionalidade, Simon Charette defendeu que aquilo "devia ser algo em que frameworks como o Celery e o RQ se ligassem", e o autor da proposta descreveu-a como uma interface para workers em segundo plano e não como um runtime. Portanto, a crítica justa não é que o Tasks esteja avariado. É que é muito mais estreito do que "tudo incluído" levava a esperar, e que a lacuna que fecha é a aborrecida: o código da sua aplicação pode enfileirar trabalho sem importar uma biblioteca de filas específica.

Portanto, orce uma fila de tarefas em qualquer projeto Django 6.1 que precise de novas tentativas, trabalho agendado ou visibilidade sobre falhas. É a mesma rubrica que era antes da 6.0 e, se esperava que esta versão a apagasse do seu diagrama de arquitetura, não apaga.

Se já decidiu que o Django serve e prefere não montar a camada de servidor do zero, o VPS Django da Cloudzy dá-lhe um ponto de partida autogerido com Django, Gunicorn, Nginx e PostgreSQL, mais acesso root quando precisar de Redis ou Celery. O servidor continua a ser seu para operar: está a saltar a configuração a partir da máquina vazia, não a responsabilidade operacional.

LER

Como Instalar o Python num Servidor VPS? | Um Guia Passo a Passo

O suporte assíncrono do Django já é suficiente?

Bom o suficiente para que "é só síncrono" já não o deva travar, e não bom o suficiente para construir por cima uma camada de dados totalmente assíncrona. Ambas as metades são verdadeiras na 6.1. Qual delas se lhe aplica depende do que está a construir e de servir sob ASGI ou WSGI, porque é essa escolha que determina se obtém uma pilha de pedidos totalmente assíncrona e um tratamento eficiente de ligações de longa duração.

O lado das capacidades não está em causa. Cada método de QuerySet que dispara SQL tem uma variante assíncrona com o prefixo a. O ciclo async for funciona em QuerySets, e as APIs assíncronas de base de dados incluem métodos de modelo como asave() e métodos de QuerySet como acreate(). Pode escrever uma view assíncrona que aguarda consultas e chamadas HTTP de saída concorrentes sem qualquer invólucro de threadpool. Comparado com o Django sobre o qual foi escrita a crítica de "apenas síncrono", este é outro framework.

O que decide o comportamento é o protocolo de implantação, não a versão do framework, e é justamente a parte que o próprio fórum do Django tem de voltar a explicar sem parar. O guia temático sobre assíncrono afirma que, sob um servidor WSGI, as views assíncronas correm no seu próprio ciclo de eventos descartável, pelo que pode usar funcionalidades assíncronas mas "não obterá os benefícios de uma pilha assíncrona".

Servir centenas de ligações sem threads de Python, streaming lento, long-polling: tudo isso exige ASGI. O mesmo código, um comportamento de concorrência diferente, e nada no framework lhe diz qual deles está a obter.

Essa confusão tem vida longa. Um utilizador com o nome tomcypress abriu um tópico no fórum do Django a perguntar porque é que pedidos consecutivos a uma view assíncrona não executavam todos o seu trabalho em segundo plano, e o habitué do fórum KenWhitesell encaminhou-o para o ciclo de eventos do WSGI. Essa troca é de 2021 e nada nela mudou na 6.1.

E é ainda reforçada de fora. A página de prós e contras do Django no TechVidvan diz aos leitores que o Django "não é capaz de lidar com vários pedidos ao mesmo tempo", o que é falso quanto ao Django 6.1 e é o tipo de afirmação que termina uma avaliação antes de ela começar. A concorrência não é algo que falte ao framework; é algo que a implantação decide.

O travão definitivo são as transações, e a própria documentação assíncrona do Django di-lo sem rodeios:

As transações ainda não funcionam em modo assíncrono. Se tiver um bocado de código que precise de comportamento transacional, recomendamos que o escreva como uma única função síncrona e o chame usando sync_to_async().

A mesma página classifica certas partes centrais do framework como "inseguras em assíncrono" e impede-as de correr num contexto assíncrono, lançando SynchronousOnlyOperation se tentar. Portanto, a forma de uma aplicação Django 6.1 assíncrona é: views assíncronas e leituras assíncronas, com ilhas síncronas onde quer que as escritas precisem de atomicidade. É praticável, e não é a mesma coisa que um framework assíncrono de raiz. A minha leitura deste eixo: melhor de forma significativa, por acabar, e um claro aprovado para tudo o que não coloque a concorrência em primeiro lugar.

O FastAPI tornou o Django a escolha padrão errada?

Para uma classe específica e crescente de projetos, sim. O Inquérito a Programadores Python de 2024 da JetBrains e da Python Software Foundation, recolhido ao longo de outubro e novembro de 2024 com mais de 30.000 participantes, colocou o FastAPI nos 38%, o Django nos 35% e o Flask nos 34% no conjunto dos inquiridos. Entre os inquiridos que escolheram desenvolvimento web como aquilo para que mais usam Python, o Django ficou nos 61%, o FastAPI nos 56% e o Flask nos 39%.

Olhe bem para essa pergunta antes de a levar a uma reunião de planeamento, porque é de escolha múltipla. Perguntou-se aos inquiridos que frameworks usam, não qual escolheram, e um programador que mantém um monólito Django enquanto escreve serviços em FastAPI conta nos dois. Não são quotas de mercado exclusivas, e aqui ninguém tem 38% de um mercado. O que mostram é um sinal repartido: o FastAPI estava à frente do Django no conjunto dos inquiridos, enquanto o Django continuava à frente do FastAPI entre os inquiridos que usam Python sobretudo para desenvolvimento web.

O inquérito específico do Django acrescenta outro sinal, vindo de quem já usa o framework. O Inquérito a Programadores Django de 2025, conduzido pela Django Software Foundation com a JetBrains sobre 4655 respostas filtradas recolhidas entre novembro de 2024 e janeiro de 2025, encontrou 82% a escrever Django profissionalmente, 77% a apontá-lo como o framework que mais usam e 48% a atualizar a cada versão estável, face a 40% um ano antes. Os inquiridos autosselecionam-se, pelo que isto descreve a base de utilizadores atual e não o mercado. A amplitude de utilização e a profundidade do compromisso são sinais diferentes, e o segundo número do Django está mais saudável do que o primeiro.

Os pontos em que o FastAPI ganha são mais estreitos e mais nítidos do que a distância no inquérito sugere. Uma superfície de API guiada por tipos, em que os seus modelos Pydantic são a camada de validação e o esquema OpenAPI gerado é o contrato, ganha ao Django mais uma camada de serializadores. O FastAPI é assíncrono de raiz na camada do pedido, mas a sua própria documentação é explícita : as operações de caminho podem ser escritas das duas maneiras, e um handler ou uma dependência declarados com um simples def correm num threadpool externo.

E um serviço sem admin, sem formulários e sem templates carrega as pilhas do Django como peso morto: está a pagar pelas opiniões do framework e a usar um quarto delas. Se é isso que está a construir, o ímpeto não é conversa e deve segui-lo.

Quem deve escolher o Django?

Recorra ao Django na 6.1 quando o admin, a autenticação, os formulários e o ORM forem a maior parte do trabalho que tem pela frente: ferramentas internas, marketplaces, SaaS de back office. Também é acertado para uma equipa pequena que precisa dessas coisas a funcionar no primeiro dia, e para uma equipa que precisa de saber já como será a sua janela de suporte em 2029.

Produtos em que as opiniões do framework cobrem a maior parte do trabalho real. Qualquer coisa com uma matriz de permissões e muito CRUD por trás de um login. Aqui, o framework tomar as decisões estruturais é a vantagem e não um custo, porque essas decisões são a maior parte do que iria construir de qualquer forma.

Equipas pequenas que precisam de ser produtivas no primeiro dia. Com três programadores e nenhum engenheiro de plataforma, uma equipa começa a escrever funcionalidades enquanto a outra começa a avaliar bibliotecas de autenticação. A partir daí, essa diferença acumula.

Equipas que já estão em Django e planeiam os próximos três anos. O Django 5.2 dá-lhe um piso com suporte até abril de 2028, e a cadência anual dá-lhe um piso previsível a seguir. Um horizonte de suporte legível vale dinheiro na hora de planear, e não é comum receber um assim tão claro.

Quem não deve escolher o Django?

Não escolha o Django para uma API de alto débito ou de streaming sem admin por trás: o FastAPI é a opção padrão mais limpa para esse formato de projeto. Não o escolha se precisa este ano de acesso assíncrono a dados, transações incluídas, porque a 6.1 não tem isso. E não o escolha à espera de que as pilhas executem os seus trabalhos em segundo plano.

Uma única API de alto débito ou de streaming, sem admin e sem superfície de formulários. Quase nada daquilo em que o Django é bom é estrutural nesta forma de projeto, pelo que estaria a manter a estrutura de um framework inteiro para um serviço que precisava de um router e de um validador.

Equipas que precisam hoje de acesso a dados totalmente assíncrono, transações incluídas. O Django 6.1 não suporta transações em modo assíncrono. Envolver as suas escritas em sync_to_async() é um padrão legítimo, não um remendo de que se livrará este ano, e onde isso for inaceitável trata-se de um impedimento e não de um arranhão.

Equipas que leem "tudo incluído" como abrangendo a execução de trabalhos em segundo plano. O Tasks não traz um worker. Se o seu plano assumia que a 6.0 retirava a fila da sua stack, o plano precisa de voltar a incluir uma fila antes de se comprometer com o framework.

Escolher que framework web aprender primeiro é outra pergunta com outra resposta; as perguntas frequentes abaixo têm a versão curta.

Saber onde o Django para é o que torna seguro começar com ele: as saídas acima veem-se antes de se comprometer, em vez de serem descobertas depois.

Perguntas frequentes