20 Jan 2026
Django community aggregator: Community blog posts
Django 6.0 Tasks: a framework without a worker
Background tasks have always existed in Django projects. They just never existed in Django itself.
For a long time, Django focused almost exclusively on the request/response cycle. Anything that happened outside that flow, such as sending emails, running cleanups, or processing uploads, was treated as an external concern. The community filled that gap with tools like Celery, RQ, and cron-based setups.
That approach worked but it was never ideal. Background tasks are not an edge case. They are a fundamental part of almost every non-trivial web application. Leaving this unavoidable slice entirely to third-party tooling meant that every serious Django project had to make its own choices, each with its own trade-offs, infrastructure requirements, and failure modes. It's one more thing that makes Django complex to deploy.
Django 6.0 is the first release that acknowledges this problem at the framework level by introducing a built-in tasks framework. That alone makes it a significant release. But my question is whether it actually went far enough.
What Django 6.0 adds
Django 6.0 introduces a brand new tasks framework. It's not a queue, not a worker system, and not a scheduler. It only defines background work in a first-party, Django-native way, and provides hooks for someone else to execute that work.
As an abstraction, this is clean and sensible. It gives Django a shared language for background execution and removes a long-standing blind spot in the framework. But it also stops there.
Django's task system only supports one-off execution. There is no notion of scheduling, recurrence, retries, persistence, or guarantees. There is no worker process and no production-ready backend. That limitation would be easier to accept if one-off tasks were the primary use case for background work, but they are not. In real applications, background work is usually time-based, repeatable, and failure-prone. Tasks need to run later, run again, or keep retrying until they succeed.
A missed opportunity
What makes this particularly frustrating is that Django had a clear opportunity to do more.
DEP 14 explicitly talks about a database backend, deferring tasks to run at a specific time in the future, and a new email backend that offloads work to the background. None of that has made it into Django itself yet. Why wasn't the database worker from django-tasks at least added to Django , or something equivalent? This would have covered a large percentage of real-world use cases with minimal operational complexity.
Instead, we got an abstraction without an implementation.
I understand that building features takes time. What I struggle to understand is why shipping such a limited framework was preferred over waiting longer and delivering a more complete story. You only get to introduce a feature once, and in its current form the tasks framework feels more confusing than helpful for newcomers. The official documentation even acknowledges this incompleteness, yet offers little guidance beyond a link to the Community Ecosystem page. Developers are left guessing whether they are missing an intended setup or whether the feature is simply unfinished.
What Django should focus on next
Currently, with Django 6.0, serious background processing still requires third-party tools for scheduling, retries, delayed execution, monitoring, and scaling workers. That was true before, and it remains true now. Even if one-off fire-and-forget tasks are all you need, you still need to install a third party package to get a database backend and worker.
DEP 14 also explicitly states that the intention is not to build a replacement for Celery or RQ, because "that is a complex and nuanced undertaking". I think this is a mistake. The vast majority of Django applications need a robust task framework. A database-backed worker that handles delays, retries, and basic scheduling would cover most real-world needs without any of Celery's operational complexity. Django positions itself as a batteries-included framework, and background tasks are not an advanced feature. They are basic application infrastructure.
Otherwise, what is the point of Django's Task framework? Let's assume that it'll get a production-ready backend and worker soon. What then? It can still only run one-off tasks. As soon as you need to schedule tasks, you still need to reach for a third-party solution. I think it should have a first-party answer for the most common cases, even if it's complex.
Conclusion
Django 6.0's task system is an important acknowledgement of a long-standing gap in the framework. It introduces a clean abstraction and finally gives background work a place in Django itself. This is good! But by limiting that abstraction to one-off tasks and leaving execution entirely undefined, Django delivers the least interesting part of the solution.
If I sound disappointed, it's because I am. I just don't understand the point of adding such a bare-bones Task framework when the reality is that most real-world projects still need to use third-party packages. But the foundation is there now. I hope that Django builds something on top that can replace django-apscheduler, django-rq, and django-celery. I believe that it can, and that it should.
20 Jan 2026 2:00am GMT
16 Jan 2026
Django community aggregator: Community blog posts
Django News - Django Packages Refresh - Jan 16th 2026
News
New Django Packages
Django Packages has a fresh new look thanks to a redesign launched this week.
Releases
Python 3.15.0 alpha 5 (yes, another alpha!)
Python 3.15.0 alpha 5 was released as a developer preview, introducing UTF8 as the default encoding, improved JIT performance, a new sampling profiler, and APIs.
Django Software Foundation
DSF member of the month - Omar Abou Mrad
Omar Abou Mrad, DSF member of the month, is a longstanding Django contributor and Discord helper who created DryORM, used by Django contributors.
Python Software Foundation
Anthropic invests $1.5 million in the Python Software Foundation and open source security
Anthropic pledged $1.5 million to the PSF to fund CPython and PyPI security improvements, including proactive automated package review and the creation of malware datasets.
Wagtail CMS News
Five sustainable ways to build habits for learning Wagtail in 2026
Sustainable ways to learn Wagtail in 2026: pace docs, split tutorials, watch conference talks, try Wagtail AI experiments, and use playful test content.
What's new in Wagtail CMS
Wagtail 7.3 features autosave, StreamField block settings, and llms.txt docs adoption, presented in live demos with previews of Wagtail AI and roadmap.
Updates to Django
Today, "Updates to Django" is presented by Pradhvan from Djangonaut Space! 🚀
Last week we had 16 pull requests merged into Django by 11 different contributors - including 2 first-time contributors! Congratulations to Amar and Andrea Zanotto for having their first commits merged into Django - welcome on board! 🥳
This week's Django highlights: 🦄
-
ExclusionConstraintnow supportsindex_type='hash'for enforcing uniqueness on large values like UIDs and URLs. (#36827) -
Contributors must now disclose AI tool usage and verify all generated output to maintain code quality. (#19594)
-
Django's
directory_indexand built-in views now adapt to the user's system dark mode preferences. (#18801) 🚀
Django Newsletter
Articles
How a Single Test Revealed a Bug in Django 6.0
Django 6.0 querystring template tag lost multiple QueryDict values by iterating items() instead of using lists(), fixed by a contributed patch.
Documenting Django's technical culture
Propose codifying Django's technical culture into meta design documents that standardize configurable component patterns to guide contributors and smooth package adoption into core.
Python: introducing tprof, a targeting profiler
tprof is a Python 3.12+ targeting profiler that measures time only inside specified functions using sys.monitoring for low overhead and quick before and after comparisons.
The coolest feature in Python 3.14
Python 3.14's sys.remote_exec enables on demand injection of debugpy into running containerized processes, allowing zero preparation remote debugging of Django apps.
How we made Python's packaging library 3x faster -
packaging 26.0rc1 speeds up Version parsing up to 2x and SpecifierSet operations up to 3x, reducing dependency resolution costs in pip.
Matthias Kestenholz's My 2025 in review
Matthias recounts 2025 personal highlights, noting web and webapp work, cautious LLM adoption, React Native iOS development, and missed Django on the Med conference.
Welcome to My Corner of the Internet (And my Year in Review)!
Marlene summarizes her 2025: DjangoCon US keynote, LangChain and MCP contributions, local SLM experiments, OSS, developer experience, and much more.
Events
Preparing for conference sprints
Prepare newcomer-friendly tasks, refresh setup documentation, and publicize sprint participation to recruit contributors and achieve concrete project outcomes during conference sprints.
DjangoCon Europe 2026: Call for Volunteers
DjangoCon Europe 2026 is looking for volunteers in Athens, offering free admission, behind-the-scenes experience, and a chance to give back to the Django community.
Podcasts
Building a Django API Framework Faster than FastAPI - Farhan Ali Raza
Farhan is a software engineer from Pakistan who added template partials to Django 6.0 as part of a Google Summer of Code project. These days, he is pushing the boundaries of what Django can do in a host of exciting new projects, most notably django-bolt, a fully typed API framework for Django that is faster than FastAPI on common performance benchmarks.
Django Job Board
This week's Django Job Board features senior and founding-level roles across Django, Python, and full-stack engineering, from mission-driven work at the Internet Archive to fully remote startup opportunities in the UK and beyond.
Senior Django Developer at SKYCATCHFIRE 🆕
Senior Python Developer at Cial Dun & Bradstreet
Software Engineer at Internet Archive
Founding Full-Stack Senior Engineer (UK ONLY) - Fully Remote at MyDataValue
Django Newsletter
Projects
sparckles/robyn
Robyn is a Super Fast Async Python Web Framework with a Rust runtime.
FarhanAliRaza/django-repl
Run Django in the browser.
This RSS feed is published on https://django-news.com/. You can also subscribe via email.
16 Jan 2026 5:00pm GMT
15 Jan 2026
Django community aggregator: Community blog posts
Building a Django API Framework Faster than FastAPI - Farhan Ali Raza
🔗 Links
- Farhan's personal site and GitHub
- django-bolt
- django-repl
- turbo-orm
- bombardier
- Robyn web framework
- Reddit thread on Django Bolt vs Django Ninja vs FastAPI
- Developer Productivity AI Arena
🎥 YouTube
Sponsor
This episode is brought to you by Six Feet Up, the Python, Django, and AI experts who solve hard software problems. Whether it's scaling an application, deriving insights from data, or getting results from AI, Six Feet Up helps you move forward faster.
See what's possible at sixfeetup.com.
15 Jan 2026 7:36pm GMT