Django 6.1 release notes | Django documentation | Django
Skip to main content
Search
Submit
Toggle theme (current theme: auto)
Toggle theme (current theme: light)
Toggle theme (current theme: dark)
Toggle Light / Dark / Auto color theme
Documentation
Getting Help
Language: en
zh-hans
sv
pt-br
pl
ko
ja
it
id
fr
es
el
Documentation version:<br>6.1
dev
Django 6.1 release notes¶
August 5, 2026
Welcome to Django 6.1!
These release notes cover the new features, as well as<br>some backwards incompatible changes you’ll<br>want to be aware of when upgrading from Django 6.0 or earlier. We’ve<br>begun the deprecation process for some features.
See the How to upgrade Django to a newer version guide if you’re updating an existing<br>project.
Mainstream support is expected to end in April 2027. Extended support is<br>expected to end in December 2027.
Python compatibility¶
Django 6.1 supports Python 3.12, 3.13, and 3.14. We highly recommend , and<br>only officially support, the latest release of each series.
What’s new in Django 6.1¶
Model field fetch modes¶
The on-demand fetching behavior of model fields is now configurable with<br>fetch modes. These modes allow you to control<br>how Django fetches data from the database when an unfetched field is accessed.
Django provides three fetch modes:
FETCH_ONE, the default, fetches the missing field for the current<br>instance only. This mode represents Django’s existing behavior.
FETCH_PEERS fetches a missing field for all instances that came from<br>the same QuerySet.
This mode works like an on-demand prefetch_related(). It can reduce most<br>cases of the “N+1 queries problem” to two queries without any work to<br>maintain a list of fields to prefetch.
FETCH_RAISE raises a FieldFetchBlocked<br>exception.
This mode can prevent unintentional queries in performance-critical<br>sections of code.
Use the new method QuerySet.fetch_mode() to set the fetch mode for model<br>instances fetched by the QuerySet:
from django.db import models
books = Book.objects.fetch_mode(models.FETCH_PEERS)<br>for book in books:<br>print(book.author.name)
Despite the loop accessing the author foreign key on each instance, the<br>FETCH_PEERS fetch mode will make the above example perform only two<br>queries:
Fetch all books.
Fetch associated authors.
See fetch modes for more details.
Database-level delete options for ForeignKey.on_delete¶
ForeignKey.on_delete now supports database-level delete options:
DB_CASCADE
DB_SET_NULL
DB_SET_DEFAULT
These options handle deletion logic entirely within the database, using the SQL<br>ON DELETE clause. They are thus more efficient than the existing<br>Python-level options, as Django does not need to load objects before deleting<br>them. As a consequence, the DB_CASCADE option does<br>not trigger the pre_delete or post_delete signals.
Mailers¶
The new MAILERS setting supports configuring multiple email backends<br>with different options, similar to existing mechanisms for CACHES,<br>DATABASES, STORAGES, and TASKS:
MAILERS = {<br>"default": {<br>"BACKEND": "django.core.mail.backends.smtp.EmailBackend",<br>"OPTIONS": {"host": "smtp.example.com", "use_tls": True},<br>},<br>"marketing": {<br>"BACKEND": "example.third.party.EmailBackend",<br>"OPTIONS": {"region": "africa-1"},<br>},
You can select a mailer with the new using argument to email sending functions, or obtain an email backend instance with<br>mail.mailers[alias]. See<br>Sending email for more details.
MAILERS is not yet enabled by default in existing projects. It will<br>replace EMAIL_BACKEND and related EMAIL_* settings in Django<br>7.0. Until then, the older settings will continue to work but will issue<br>deprecation warnings: see the list of email deprecations below.
You can opt into the new feature at any time before Django 7.0; see<br>Migrating email to mailers. To ease the transition,<br>mail.mailers["default"] works with<br>either MAILERS or the deprecated EMAIL_BACKEND setting<br>defined. The deprecated get_connection() function will<br>also return an instance of the default mailer when MAILERS is<br>defined.
Minor features¶
django.contrib.admin¶
The admin site login view now redirects authenticated users to the next URL,<br>if available, instead of always redirecting to the admin index page.
The admin’s FilteredSelectMultiple widget now uses s to<br>preserve named groups (e.g.<br>choices=[("Group", [("1", "Item")]), ...]).
When ModelAdmin.list_select_related is False (the default),<br>the change list now selects only the foreign key fields specified in<br>ModelAdmin.list_display, rather than all foreign key fields. This<br>should improve performance for models with many foreign key fields.
The delete_confirmation_max_display<br>option allows customizing how many objects are displayed on admin delete<br>confirmation pages and inline protected deletion errors before the remainder<br>is truncated. The default is None (no truncation).
In order to improve accessibility of the admin change forms:
Form fields are now shown below their respective labels instead of next to<br>them.
Help text is now shown...