Análisis de Django: ¿sigue mereciendo la pena?

Django publicó dos versiones de funcionalidades y reescribió por completo su cadencia de lanzamientos en los ocho meses que van de diciembre de 2025 a agosto de 2026.

Todo eso le ocurrió a un framework cuya reputación apenas ha cambiado desde 2023: el framework de Python con pilas incluidas, productivo, opinado, solo síncrono y que pierde terreno frente a FastAPI. La etiqueta de «solo síncrono» está caducada, y la historia de su popularidad es más complicada de lo que sugieren los titulares.

Así que esta es mi conclusión sobre si Django sigue mereciendo la pena en la 6.1: un veredicto con nota, los tipos de proyecto que le encajan y aquellos en los que FastAPI es ahora la mejor opción.

La versión corta

Sí, con condiciones. Django 6.1 sigue siendo la mejor opción por defecto cuando el admin, la autenticación, los formularios y el ORM son la mayor parte del trabajo, y la brecha asíncrona se ha estrechado lo bastante como para que «solo síncrono» ya no sea motivo para descartarlo. No sirve para una única API de alta concurrencia sin superficie de administración. 4 sobre 5.

• Lo que compras es el paquete completo. El ORM, las migraciones, la autenticación por sesión con permisos, una capa de formularios y un admin generado llegan juntos y ya integrados, no como cinco bibliotecas más las costuras entre ellas.
• Los trabajos en segundo plano son el eje débil. El framework Tasks de Django 6.0 te da un decorador y una llamada de encolado, pero ningún worker, así que Celery o un equivalente sigue siendo una decisión tuya.
• El soporte asíncrono es mucho mejor y claramente incompleto. Django admite vistas asíncronas y llamadas asíncronas al ORM, pero las transacciones no funcionan en modo asíncrono. Bajo WSGI, las vistas asíncronas todavía pueden ejecutar E/S asíncrona concurrente dentro de una petición, pero no obtienes las ventajas de una pila de peticiones totalmente asíncrona: las peticiones de larga duración y la alta concurrencia de conexiones requieren ASGI.
• Planificar más allá de 2027 se ha vuelto más fácil. A partir de enero de 2028, Django publica una versión de funcionalidades al año, cada una con tres años de soporte, y la etiqueta «LTS» desaparece porque ahora todas las versiones reciben ese compromiso.
• Adecuado para productos con mucho admin y mucho CRUD, y para equipos pequeños. Inadecuado para una única API de alto rendimiento o de streaming, sin admin ni formularios, donde FastAPI es la elección más natural.

Cómo he hecho este análisis: Esta es una evaluación de Django 6.1 construida a partir de las notas de versión y la documentación del propio proyecto, del anuncio de gobernanza de la Django Software Foundation de agosto de 2026, de las encuestas a desarrolladores de JetBrains/PSF de 2024 y de Django de 2025, y de profesionales identificados que escriben públicamente sobre su propia experiencia en producción. No hice una prueba en producción de varias semanas para este artículo, y aquí no hay benchmarks: no se hizo ninguna prueba de carga. Django es gratuito y tiene licencia BSD, y yo no tengo ninguna relación con el proyecto.

¿Qué ha cambiado realmente en Django desde 2025?

Django 6.0 llegó el 3 de diciembre de 2025 con un framework Tasks de primera parte y otras incorporaciones al núcleo. La interfaz asíncrona del ORM es más antigua: Django 4.1 introdujo las operaciones asíncronas de QuerySet en 2022. Django 6.1 pasó a ser la versión estable actual el 5 de agosto de 2026. Después, el 10 de agosto de 2026, el proyecto anunció una versión de funcionalidades al año a partir de enero de 2028, tres años de soporte para cada versión y el fin de la etiqueta LTS.

Las notas de la versión 6.1 confirman que la 6.1 admite Python 3.12, 3.13 y 3.14, con el soporte principal terminando en abril de 2027 y el extendido en diciembre de 2027.

Los números de versión cambian con ello. Llevan el año: Django 2028, luego Django 2029 (al menos «¿en qué versión estás?» se vuelve más fácil de responder). Los tres años se reparten en un año de correcciones de errores normales seguido de dos de correcciones de seguridad y de pérdida de datos, que es lo que significaba LTS, así que la etiqueta desaparece.

Eso deja una ventana incómoda para un proyecto que empiece hoy. Django 5.2 es la LTS actual, con soporte hasta abril de 2028. Django 6.1 es la estable actual, pero su soporte extendido termina en diciembre de 2027, unos cuatro meses antes de que la ventana de soporte de Django 5.2 acabe en abril de 2028.

Así que: buscar la ventana de soporte más larga significa empezar en la 5.2. Querer el framework Tasks y las últimas funciones de la rama 6.x significa empezar en la 6.1 y aceptar otra actualización antes. Ninguna opción está mal, y la elección incómoda desaparece cuando llegue Django 6.2 LTS en abril de 2027.

Yo leo el cambio de cadencia como una buena señal. Los proyectos en declive estiran sus promesas de soporte en silencio; no las reestructuran en público con un plan fechado. Este simplificó un compromiso que ya estaba cumpliendo.

Lo que Django sigue haciendo mejor que nada

Arranca un proyecto Django 6.1 y ya tienes autenticación por sesión funcionando con un sistema de permisos, una capa de formularios que valida y renderiza, un sistema de migraciones ligado a tus modelos, el ORM y un admin generado, antes de escribir una sola funcionalidad. Ese es todo el argumento, y es la parte de Django que no ha necesitado cambiar.

El valor no está en que esas piezas existan. Está en que fueron diseñadas unas contra otras. Los mismos permisos de modelo alimentan el admin, y un cambio en un modelo genera la migración y actualiza el formulario del admin de una sola vez.

Ensamblar una cobertura equivalente a partir de bibliotecas independientes acaba por llevarte allí. También te deja una superficie de mantenimiento permanente en cada costura, y las costuras son donde viven los errores.

El admin es una herramienta para el personal interno. La referencia del admin dice que su uso recomendado se limita a la herramienta de gestión interna de una organización y que no está pensada para construir todo tu front-end alrededor de ella. Los permisos de modelo controlan qué pueden hacer los usuarios internos una vez dentro, y entrar siquiera exige is_staff. Tómalo como una restricción y es una buena: obtienes gratis un back office interno competente y no obtienes una interfaz de cara al cliente, así que nadie se ve tentado de publicar una.

Los valores de seguridad por defecto son la otra mitad del mismo argumento. La protección CSRF, la parametrización de SQL a través del ORM, el escapado de XSS en las plantillas y la protección contra clickjacking vienen activados de fábrica, en lugar de ser cosas que un desarrollador veterano tenga que acordarse de pedir en la revisión. Un equipo pequeño hereda decisiones tomadas por gente que ha leído una década de informes de seguridad.

Luego está la edad. Se lee como un lastre; yo la leo como el argumento del ecosistema. Django REST Framework existe y es aburrido justo en el sentido en que quieres que la infraestructura sea aburrida.

Lo mismo pasa con los paquetes maduros para los problemas que aparecen en el cuarto mes: filtrado, limitación de peticiones, backends de almacenamiento, patrones multiinquilino, registros de auditoría. Y cuando un problema es lo bastante raro como para que ningún paquete lo cubra, normalmente hay un hilo de lista de correo de hace quince años sobre él. En amplitud no creo que haya nada más en Python que se acerque, y es ese eje el que hace que alguien elija Django en primer lugar.

Dónde se queda corto Django

Django sigue sin un tipado nativo completo en todo el framework, su ritmo conservador deja huecos de los que «pilas incluidas» no te avisa, y el framework Tasks de la 6.0 no tiene worker. Esas son las tres carencias en la 6.1. El hueco del tipado es el que te fastidia a diario; Tasks es el que cambia tu diagrama de arquitectura.

El grueso del tipado lo sigues montando con herramientas de terceros. django-stubs aporta stubs de tipos más un plugin de mypy específico para el comportamiento dinámico de Django. Su documentación actual indica soporte completo de mypy y soporte básico de pyright, pyrefly y ty. Es una situación mejor que antes, pero sigue siendo una capa de compatibilidad aparte y no un tipado nativo completo dentro del propio Django.

Viniendo de un framework construido alrededor de las anotaciones de tipos, es una regresión medible en la experiencia diaria dentro del editor.

El ritmo conservador es tanto un coste como una virtud. Django añade cosas con cuidado y tarde, y por eso el framework que aprendiste en 2019 es el que puedes leer hoy. También por eso las pilas se acaban donde se acaban: no hay capa de WebSocket en el núcleo, no hay planificador, no hay opinión sobre la orquestación de tareas asíncronas. Cruza una de esas líneas y vuelves a montar las cosas por tu cuenta.

¿Django 6 sigue necesitando Celery?

Celery en concreto, no. El framework Tasks de Django 6.0 estandariza cómo se define y se encola una tarea, pero no ejecuta él mismo el trabajo encolado. En producción sigues necesitando un backend o un proceso worker que ejecute las tareas; Celery es una opción, no un requisito del framework. Las notas de la versión de Django 6.0 son tajantes respecto al límite: Django se encarga de crear y encolar las tareas, pero no aporta ningún mecanismo de worker, y la ejecución debe gestionarla una infraestructura externa, como un proceso o servicio aparte.

Lo que obtienes es la interfaz:

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(...) envía la tarea a un backend configurado. Los dos backends que vienen con la 6.0 están pensados para desarrollo y pruebas (así que no es el que esperabas). La programación, la recurrencia, los reintentos y la durabilidad quedan todos fuera del alcance.

Kevin Renskers, desarrollador Django en activo, lo formuló de la manera más rotunda en su análisis de Tasks:

En vez de eso, nos dieron una abstracción sin implementación.

Tiene razón en cuanto a la forma. Yo plantearía la intención de otro modo. En la votación del Steering Council sobre DEP 14, la propuesta de mejora de Django detrás de la funcionalidad, Simon Charette sostuvo que «debería ser algo a lo que se enchufen frameworks como Celery y RQ», y el autor de la propuesta la describió como una interfaz de workers en segundo plano y no como un runtime. Así que la crítica justa no es que Tasks esté roto. Es que es mucho más estrecho de lo que «pilas incluidas» hacía esperar, y el hueco que tapa es el aburrido: el código de tu aplicación puede encolar trabajo sin importar una biblioteca de colas concreta.

Así que presupuesta una cola de tareas en cualquier proyecto Django 6.1 que necesite reintentos, trabajo programado o visibilidad de los fallos. Es la misma partida que era antes de la 6.0, y si esperabas que esta versión la borrara de tu diagrama de arquitectura, no lo hace.

Si ya has decidido que Django encaja y prefieres no montar la capa de servidor desde cero, el VPS Django de Cloudzy te da un punto de partida autogestionado con Django, Gunicorn, Nginx y PostgreSQL, más acceso root cuando necesites Redis o Celery. El servidor sigue siendo tuyo de operar: te saltas el montaje desde la máquina en blanco, no la responsabilidad operativa.

LEER

¿Cómo instalar Python en un servidor VPS? Una guía paso a paso

¿El soporte asíncrono de Django ya es suficiente?

Lo bastante bueno como para que «solo es síncrono» ya no te frene, y no lo bastante como para construir encima una capa de datos totalmente asíncrona. Ambas mitades son ciertas en la 6.1. Cuál te aplica depende de lo que estés construyendo y de si lo sirves bajo ASGI o WSGI, porque esa elección determina si obtienes una pila de peticiones totalmente asíncrona y un manejo eficiente de conexiones de larga duración.

El lado de las capacidades no se discute. Cada método de QuerySet que dispara SQL tiene una variante asíncrona con el prefijo a. El bucle async for funciona sobre los QuerySets, y las API asíncronas de base de datos incluyen métodos de modelo como asave() y métodos de QuerySet como acreate(). Puedes escribir una vista asíncrona que espere consultas y llamadas HTTP salientes concurrentes sin ningún envoltorio de threadpool. Comparado con el Django sobre el que se escribió la crítica de «solo síncrono», es otro framework.

Lo que decide el comportamiento es el protocolo de despliegue, no la versión del framework, y es justo la parte que el foro de Django tiene que volver a explicar una y otra vez. La guía temática sobre asincronía afirma que, bajo un servidor WSGI, las vistas asíncronas se ejecutan en su propio bucle de eventos de un solo uso, de modo que puedes usar funciones asíncronas pero «no obtendrás los beneficios de una pila asíncrona».

Atender cientos de conexiones sin hilos de Python, el streaming lento, el long-polling: todo eso requiere ASGI. El mismo código, un comportamiento de concurrencia distinto, y nada en el framework te dice cuál estás obteniendo.

Esa confusión tiene una vida larga. Un usuario que firmaba como tomcypress abrió un hilo en el foro de Django preguntando por qué peticiones consecutivas a una vista asíncrona no ejecutaban todas su trabajo en segundo plano, y el habitual del foro KenWhitesell le señaló el bucle de eventos de WSGI. Ese intercambio es de 2021 y nada de eso ha cambiado en la 6.1.

Además, se refuerza desde fuera. La página de pros y contras de Django en TechVidvan dice a los lectores que Django «no es capaz de manejar múltiples peticiones al mismo tiempo», lo cual es falso para Django 6.1 y es el tipo de afirmación que acaba con una evaluación antes de empezarla. La concurrencia no es algo que le falte al framework: es algo que decide el despliegue.

El freno definitivo son las transacciones, y la propia documentación asíncrona de Django lo dice sin rodeos:

Las transacciones todavía no funcionan en modo asíncrono. Si tienes una porción de código que necesita comportamiento transaccional, te recomendamos escribir esa porción como una única función síncrona y llamarla usando sync_to_async().

La misma página clasifica ciertas partes clave del framework como «no seguras en asíncrono» y les impide ejecutarse en un contexto asíncrono, lanzando SynchronousOnlyOperation si lo intentas. Así que la forma de una aplicación Django 6.1 asíncrona es: vistas asíncronas y lecturas asíncronas, con islas síncronas allí donde las escrituras necesitan atomicidad. Es viable, y no es lo mismo que un framework nativamente asíncrono. Mi valoración en este eje: mejor de forma apreciable, sin terminar, y un aprobado claro para todo lo que no ponga la concurrencia por delante.

¿Ha convertido FastAPI a Django en la opción por defecto equivocada?

Para una categoría concreta de proyectos, y creciente, sí. La Encuesta de Desarrolladores Python de 2024 de JetBrains y la Python Software Foundation, recogida durante octubre y noviembre de 2024 con más de 30.000 participantes, sitúa a FastAPI en el 38 %, a Django en el 35 % y a Flask en el 34 % sobre el total de encuestados. Entre quienes eligieron el desarrollo web como aquello para lo que más usan Python, Django estaba en el 61 %, FastAPI en el 56 % y Flask en el 39 %.

Mira bien esa pregunta antes de llevarla a una reunión de planificación, porque es de selección múltiple. Se preguntó a los encuestados qué frameworks usan, no cuál eligieron, y un desarrollador que mantiene un monolito Django mientras escribe servicios FastAPI cuenta en ambos. No son cuotas de mercado excluyentes, y aquí nadie tiene el 38 % de un mercado. Lo que muestran es una señal partida: FastAPI iba por delante de Django entre todos los encuestados, mientras que Django seguía por delante de FastAPI entre quienes usan Python sobre todo para desarrollo web.

La encuesta específica de Django añade otra señal, procedente de quienes ya usan el framework. La Encuesta de Desarrolladores Django de 2025, realizada por la Django Software Foundation con JetBrains sobre 4.655 respuestas filtradas recogidas entre noviembre de 2024 y enero de 2025, encontró un 82 % que escribe Django profesionalmente, un 77 % que lo señala como su framework más usado y un 48 % que actualiza con cada versión estable, frente al 40 % del año anterior. Los encuestados se autoseleccionan, así que describe la base de usuarios actual y no el mercado. La amplitud de uso y la profundidad del compromiso son señales distintas, y el segundo número de Django está más sano que el primero.

Los sitios donde gana FastAPI son más estrechos y más nítidos de lo que sugiere la separación de la encuesta. Una superficie de API guiada por tipos, donde tus modelos Pydantic son la capa de validación y el esquema OpenAPI generado es el contrato, le gana a Django más una capa de serializadores. FastAPI es asíncrono de origen en la capa de petición, pero su propia documentación es explícita : las operaciones de ruta pueden escribirse de las dos maneras, y un manejador o una dependencia declarados con un simple def se ejecutan en un pool de hilos externo.

Y un servicio sin admin, sin formularios y sin plantillas lleva las pilas de Django como peso muerto: pagas por las opiniones del framework y usas una cuarta parte. Si eso es lo que estás construyendo, el impulso no es humo y deberías seguirlo.

¿Quién debería elegir Django?

Recurre a Django en la 6.1 cuando el admin, la autenticación, los formularios y el ORM sean la mayor parte del trabajo que vas a hacer: herramientas internas, marketplaces, SaaS de back office. También es acertado para un equipo pequeño que necesita todo eso funcionando desde el primer día, y para un equipo que necesita saber ya cómo será su ventana de soporte en 2029.

Productos en los que las opiniones del framework cubren la mayor parte del trabajo real. Cualquier cosa con una matriz de permisos y mucho CRUD detrás de un inicio de sesión. Aquí que el framework tome las decisiones estructurales es la ventaja y no un coste, porque esas decisiones son la mayor parte de lo que ibas a construir de todos modos.

Equipos pequeños que necesitan ser productivos desde el primer día. Con tres desarrolladores y ningún ingeniero de plataforma, un equipo empieza a escribir funcionalidades mientras el otro empieza a evaluar bibliotecas de autenticación. A partir de ahí, esa distancia se acumula.

Equipos que ya están en Django y planifican los próximos tres años. Django 5.2 te da un suelo con soporte hasta abril de 2028, y la cadencia anual te da otro predecible después. Un horizonte de soporte legible vale dinero a la hora de planificar, y no es habitual que te lo entreguen con esta claridad.

¿Quién no debería elegir Django?

No elijas Django para una API de alto rendimiento o de streaming sin admin detrás: FastAPI es la opción por defecto más limpia para esa forma de proyecto. No lo elijas si necesitas este año acceso asíncrono a datos, transacciones incluidas, porque la 6.1 no lo tiene. Y no lo elijas esperando que las pilas ejecuten tus trabajos en segundo plano.

Una única API de alto rendimiento o de streaming, sin admin ni superficie de formularios. Casi nada de lo que Django hace bien es estructural para esta forma de proyecto, así que estarías manteniendo la estructura de un framework entero para un servicio que necesitaba un enrutador y un validador.

Equipos que necesitan hoy un acceso a datos totalmente asíncrono, transacciones incluidas. Django 6.1 no admite transacciones en modo asíncrono. Envolver tus escrituras en sync_to_async() es un patrón legítimo, no un apaño del que te librarás este año, y allí donde resulte inaceptable es un bloqueo y no un rasguño.

Equipos que leen «pilas incluidas» como si cubriera la ejecución de trabajos en segundo plano. Tasks no incluye ningún worker. Si tu plan daba por hecho que la 6.0 eliminaba la cola de tu stack, el plan necesita volver a incluir una cola antes de que te comprometas con el framework.

Elegir qué framework web aprender primero es otra pregunta con otra respuesta; las preguntas frecuentes de abajo tienen la versión corta.

Saber dónde se detiene Django es lo que hace seguro empezar con él: las salidas anteriores se ven antes de comprometerse, en vez de descubrirse después.

Preguntas frecuentes