Django 6.1 salió el 5 de agosto de 2026, y con él Django 6.0 pasa a la fase de soporte reducido: a partir de ahora solo recibirá parches de seguridad y de pérdida de datos hasta abril de 2027. Toca actualizar si se quiere seguir con soporte completo.
La versión no viene cargada de features rompedoras, pero trae tres cambios que se notan en el día a día de cualquier proyecto con modelos medianamente grandes.
Fetch modes por campo
Django 6.1 permite configurar el comportamiento de carga bajo demanda a nivel de campo del modelo, en vez de depender solo de select_related() o prefetch_related() en cada consulta. Es un control más fino sobre cuándo se trae un campo desde la base de datos y cuándo se difiere, útil en modelos con columnas pesadas (JSON grandes, blobs, texto largo) que no siempre hacen falta.
Borrado a nivel de base de datos para ForeignKey.on_delete
Hasta ahora, las políticas de on_delete las resolvía Django en la capa de aplicación: cuando se borraba un registro padre, el ORM se encargaba de propagar el CASCADE, poner a NULL las claves foráneas o lo que tocara. Con esta versión, esas operaciones se pueden delegar directamente a la base de datos, aprovechando las constraints nativas en vez de que Django tenga que calcular y ejecutar el borrado en cascada consulta a consulta. En tablas grandes, con muchas relaciones, la diferencia de rendimiento puede ser considerable.
Configuración de email por diccionario
La configuración de email gana una forma más ordenada de definirse, agrupando los parámetros en un diccionario en vez de repartirlos entre media docena de settings sueltos (EMAIL_HOST, EMAIL_PORT, EMAIL_USE_TLS...). Encaja mejor con proyectos que gestionan varios backends de email o que cargan la configuración desde variables de entorno estructuradas.
El parche de seguridad de GeoDjango, un día antes
El 4 de agosto, un día antes de Django 6.1, salieron las versiones de seguridad 6.0.8 y 5.2.17. Corrigen un fallo de denegación de servicio en GEOSGeometry: objetos GEOMETRYCOLLECTION anidados de forma muy profunda podían provocar un segmentation fault en GEOS, la librería geométrica que usa GeoDjango por debajo.
La solución pone límites explícitos, una profundidad máxima de anidación de 198 para entrada WKT y un máximo de 198 colecciones para WKB. Si tu proyecto usa GeoDjango y acepta geometría de origen externo (subida por usuarios, por ejemplo), conviene actualizar cuanto antes: es el tipo de vulnerabilidad que se dispara con un solo payload malicioso, sin necesidad de acceso privilegiado.
Qué hacer con esto
Si el proyecto está en Django 6.0, la actualización a 6.1 es sencilla, ninguno de los tres cambios grandes es obligatorio: los fetch modes y el borrado a nivel de BBDD hay que activarlos explícitamente, así que el comportamiento por defecto no cambia solo por actualizar. Lo que sí conviene revisar cuanto antes es el parche de GeoDjango si se trabaja con datos geoespaciales de fuentes no controladas.
Más detalles en Python This Week, que recoge esta y otras novedades del ecosistema Python de la semana.
Relacionado: 14 librerías de Python que multiplican tu productividad y cómo dockerizar aplicaciones Python.