Hire Django developers in 2026: DEP 20 retires LTS and Django 6.1 drops four database versions

Summary. On 10 August 2026 Django's Steering Council accepted DEP 20, moving Django to an annual release cycle from January 2028. Every feature release then gets "the LTS-level three years of support", version numbers become the release year, and the "LTS" label is retired outright. Five days earlier, on 5 August 2026, Django 6.1 shipped and quietly dropped support for PostgreSQL 14, MySQL below 8.4, MariaDB below 10.11 and SQLite below 3.37.0. Django 4.2 LTS died on 7 April 2026. There has been a security release every month from February to August 2026, and the 4 August batch alone carried four CVEs including one rated high. In the most recent Django Developers Survey, 4,655 respondents, 4% were running an unsupported version. Hire Django developers against that, not against a tutorial.

What DEP 20 actually changes

The announcement, posted by Carlton Gibson on 10 August 2026, is short and worth quoting rather than paraphrasing.

The core change: "From January 2028, Django will make one feature release a year, giving every feature release the LTS-level three years of support, and version numbers will carry the feature release year: Django 2028, then Django 2029, and so on."

The support shape: "Every feature release gets three years of support: one year of mainstream bugfixes, then two years of security and data-loss fixes. The 'LTS' label is retired, every feature release now carries that same, unique commitment."

And the reason it matters for planning: "No more LTS gap: no racing a deadline to jump two years of changes at once. Upgrade one year at a time, whenever suits you within the support window. Three versions are supported at any time, giving third-party packages a clear, rolling target."

Python support is now tied to it as well: "each Django version supports the three latest Python versions at release, and picks up the new Python version during its first year. Django's support window ends in step with its oldest supported Python." That couples your Django plan to your Python plan, which is why this page and our Python developer hiring guide belong together.

Nothing changes before 2028, and the announcement says so: "Support commitments for Django 5.2 LTS and 6.2 LTS stand as made."

Release	First release	End of mainstream	End of extended
4.2 LTS	Apr 2023	4 Dec 2023	7 Apr 2026 (dead)
5.2 LTS	Apr 2025	3 Dec 2025	Apr 2028
6.0	Dec 2025	4 Aug 2026	Apr 2027
6.1	5 Aug 2026	Apr 2027	Dec 2027
6.2 LTS	Apr 2027	Dec 2027	Apr 2030
Django 2028	Jan 2028	Jan 2029	Jan 2031

Django 6.2 is, in the project's words, "the final release under the previous versioning and support policy".

Django 6.1 is a bigger upgrade than the version number suggests

The headline feature is the one that changes how ORM code gets reviewed. Django 6.1 adds QuerySet.fetch_mode() with three modes. FETCH_ONE is the default and preserves existing behaviour. FETCH_PEERS "fetches a missing field for all instances that came from the same QuerySet" and, per the release notes, "can reduce most cases of the 'N+1 queries problem' to two queries without any work to maintain a list of fields to prefetch". FETCH_RAISE raises FieldFetchBlocked, which "can prevent unintentional queries in performance-critical sections of code".

That last one is the interesting hire signal. FETCH_RAISE turns an invisible performance bug into a test failure. Katherine "Kati" Michel, a software engineer at JPMorganChase working in Infrastructure Platforms, described the old workflow in a Django Software Foundation post on 29 July 2026: "I had a website query that was becoming progressively slower as the data in the database grew. I installed django-silk, a live profiling and inspection library, diagnosed an N+1 problem, and had an aha moment as I watched the number of SQL queries in the django-silk dashboard greatly reduce with each new addition of a prefetch_related or select_related." Django 6.1 makes that discoverable at development time instead.

Second, ForeignKey.on_delete gains database-level options: DB_CASCADE, DB_SET_NULL and DB_SET_DEFAULT. These "handle deletion logic entirely within the database, using the SQL ON DELETE clause" and are more efficient because Django does not load objects before deleting them. The catch is stated plainly: "the DB_CASCADE option does not trigger the pre_delete or post_delete signals". If your audit trail, cache invalidation or search reindexing hangs off post_delete, switching to DB_CASCADE silently stops it. That is a review question, not a config question.

Third, the MAILERS setting arrives, supporting multiple email backends the way CACHES and DATABASES do. It "will replace EMAIL_BACKEND and related EMAIL_* settings in Django 7.0", with deprecation warnings until then.

And the infrastructure bill that nobody budgets for: Django 6.1 dropped PostgreSQL 14 (upstream support ends November 2026), MySQL below 8.4 (upstream 8.0 support ended April 2026), MariaDB below 10.11, and raised the minimum SQLite from 3.31.0 to 3.37.0. Django 6.1 supports Python 3.12, 3.13 and 3.14, and the release notes add: "We highly recommend, and only officially support, the latest release of each series." A Django 6.1 upgrade is a database upgrade with a framework upgrade attached.

The security cadence is monthly, and the reports are getting noisier

Django shipped security releases in February, March, April, May, June, July and August 2026. The 4 August batch (Django 6.0.8 and 5.2.17) covered four CVEs: CVE-2026-15307, "server-side file-write and request forgery via spatial lookups", rated high; CVE-2026-15830, a denial of service via nested geometry collections, moderate, now capped at a depth of 198 GEOMETRYCOLLECTIONs; CVE-2026-15920, cross-site scripting via URLField values in the admin, moderate; and CVE-2026-15337, a low-severity denial of service in check_for_language(). Django 4.2 is not in the affected list, because it is already dead.

The February batch was worse in kind: six CVEs including three SQL injection issues, one via raster lookups on PostGIS, one via column aliases with control characters, and one via QuerySet.order_by and FilteredRelation.

There is also a change in the report stream that the security team wrote up on 4 February 2026: "Almost every report now is a variation on a prior vulnerability", and "on a nearly daily basis we get reports duplicating other pending reports, or even reports about vulnerabilities that have already been fixed and publicized. Clearly, reporters are using LLMs to generate (initially) plausible variations." The team also notes that "security releases come with costs to the community. They interrupt our users' development workflows, and they also severely interrupt ours."

The operational read is simple. Assume a Django patch every month, assume it will be unscheduled, and make sure someone owns it.

What the survey says about how teams really upgrade

The 2025 Django Developers Survey, the fourth annual report from the Django Software Foundation with PyCharm, was fielded from November 2024 to January 2025 and drew 4,655 responses after filtering. A 2026 survey closed on 13 July 2026 but its results are not published, so these are the current published figures.

• 82% write Django code professionally.
• 75% use the latest stable release for new projects; 21% use the latest LTS.
• 48% upgrade every stable release, up from 40% the year before; 27% move on LTS only; 4% run an unsupported version.
• Versions in use: 62% on 5.1, 45% on 4.2, 12% on 3.2.
• PostgreSQL leads at 76%, then SQLite 42%, MySQL 27%, MariaDB 9%.
• 63% use type hints in their Django code, and 84% want them added to Django core.
• Third-party packages: Django REST Framework 49%, django-debug-toolbar 27%, django-celery 26%.
• 30% have 11 or more years of professional coding experience.

Two of those numbers change the hiring brief. The 27% on an LTS-only cadence are the group DEP 20 is aimed at, and from 2028 their strategy stops existing as a distinct option. And the 45% who were on 4.2 when surveyed are now on a version that died on 7 April 2026, unless they moved.

What to test for when you hire Django developers

Django interviews still test models, views and templates, which every candidate can do. Test the things that decide whether a Django codebase survives an upgrade.

• What does FETCH_PEERS change about the N+1 problem, and when would you use FETCH_RAISE instead?
• You switch a ForeignKey to DB_CASCADE. What stops working?
• Which Django versions are supported today, and what happens to that list in January 2028?
• Your project runs PostgreSQL 14. What blocks the Django 6.1 upgrade?
• MAILERS is deprecated-adjacent right now. When does EMAIL_BACKEND actually stop working?

Every one of those is answerable in conversation, and every one separates someone who reads release notes from someone who reads Stack Overflow.

Engagement models

This page is deliberately separate from our Django development company page. That covers building an application. This covers who owns the framework version after it ships.

Model	Fits when	Fails when
Dedicated Django engineers, monthly	You own the roadmap and need capacity plus upgrade ownership	The need is one fixed deliverable with an end date
Embedded pod with a tech lead	No senior Django voice in-house; ORM review standards need setting	You already have a strong lead and need only hands
Capped migration engagement	Known shape, such as 4.2 to 5.2 LTS plus the PostgreSQL 15 move	Requirements are still being discovered
Security patch retainer	Monthly Django releases need applying without derailing a sprint	Nothing ships and nothing needs patching
Fixed scope	Well-specified application with pinned dependencies	Django and its database floors move mid-build

For teams still on Django 4.2, the sequence matters more than the size: database upgrade first, then Django, then the ORM review that FETCH_RAISE makes possible. Doing it in the other order is how a two-week job becomes a quarter.

India-specific considerations

The Digital Personal Data Protection Act 2023 puts breach handling on a statutory footing for Indian operators, and Django's 2026 CVE list is directly relevant: three SQL injection issues in February and a server-side file-write plus request-forgery issue in August, all in code paths that touch user-supplied data. Running Django 4.2 in production in India today means running a framework that will not receive a fix when the next one lands.

The practical structure for most Indian product teams is a named owner for the monthly patch cycle plus a scheduled annual upgrade, delivered in-house, through staff augmentation services or as a dedicated offshore product engineering team. DEP 20 makes that easier from 2028, because the upgrade becomes a predictable yearly event rather than a two-year cliff. Until then, the cliff is still there.

FAQ

What is DEP 20 and when does it take effect?

DEP 20 is the Django Enhancement Proposal accepted by the Steering Council on 10 August 2026. From January 2028, Django ships one feature release a year, every release gets three years of support, the LTS label is retired, and versions are named by year. Django 6.2 is the last release under the old policy.

Which Django versions are supported right now?

As of 18 August 2026, three: Django 5.2 LTS with extended support to April 2028, Django 6.0 with extended support to April 2027, and Django 6.1, released 5 August 2026, with mainstream support to April 2027. Django 4.2 LTS reached end of extended support on 7 April 2026 and receives nothing.

What breaks when we upgrade to Django 6.1?

Database floors move: PostgreSQL 14, MySQL below 8.4 and MariaDB below 10.11 are dropped, and SQLite must be 3.37.0 or newer. Python support narrows to 3.12, 3.13 and 3.14. Application code mostly survives, but EMAIL_BACKEND settings begin issuing deprecation warnings ahead of MAILERS in Django 7.0.

Does DB_CASCADE fire Django signals?

No. The Django 6.1 release notes state that DB_CASCADE handles deletion entirely in the database using the SQL ON DELETE clause, and as a consequence "does not trigger the pre_delete or post_delete signals". Any audit logging, cache invalidation or search reindexing hanging off those signals will stop running silently.

How does fetch_mode fix the N+1 problem?

QuerySet.fetch_mode(models.FETCH_PEERS) fetches a missing field for every instance from the same QuerySet, working like an on-demand prefetch_related(). The release notes say it "can reduce most cases of the N+1 queries problem to two queries without any work to maintain a list of fields to prefetch". FETCH_RAISE blocks the query instead.

How often does Django ship security releases?

Monthly through 2026 so far. There were security releases in February, March, April, May, June, July and August. The 4 August 2026 batch carried four CVEs, one rated high, and the February batch carried six including three SQL injection issues. Budget for an unscheduled patch every month.

How many Django teams run unsupported versions?

In the 2025 Django Developers Survey, fielded from November 2024 to January 2025 with 4,655 responses, 4% said they use an unsupported version of Django. A further 45% were on 4.2 at the time of the survey, which reached end of extended support on 7 April 2026, and 12% were still on 3.2.

Should we wait for DEP 20 before planning upgrades?

No. DEP 20 changes nothing before January 2028, and the announcement confirms support commitments for Django 5.2 LTS and 6.2 LTS stand as made. If you are on 4.2 you are already unsupported, and the database version floors in 6.1 mean the work grows the longer it waits.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. On Django work we take the sequencing that gets botched: moving the database first, then Django 4.2 or 5.x forward, then using FETCH_RAISE to surface the N+1 queries that were always there, and owning the monthly security releases so they stop landing mid-sprint. We staff that as embedded engineers or as a capped migration, and we will say which one your codebase needs. Talk to us at /contact-us/.

References

1. Django moves to an annual release cycle - Carlton Gibson, 10 August 2026
2. Django 6.1 released - Jacob Walls, 5 August 2026
3. Django 6.1 release notes - Django documentation
4. Download Django and supported versions - Django Project
5. Django security releases, 4 August 2026 - Natalia Bidart
6. Django security releases, 3 February 2026 - Jacob Walls
7. Recent trends observed by the security team - Jacob Walls, 4 February 2026
8. Django Developers Survey 2025 results - William Vincent, 31 October 2025
9. Django Developer Survey 2025 full report - Django Software Foundation and PyCharm
10. DSF member of the month: Katherine Michel - Sarah Abderemane, 29 July 2026
11. Last call for the 2026 Django Developer Survey - Django Project

Last updated: 18 August 2026.