Django: Query Performance & GIS Reliability Improvements

Transcript

Hey there, Django developers! Welcome back to another episode of the Django podcast. It's February 7th, 2026, and I'm so excited to catch up with you about what's been happening in our favorite web framework. Grab your coffee - or whatever fuels your coding sessions - because we've got some really thoughtful improvements to dive into today.

So yesterday was quite productive for the Django project! We saw three pull requests get merged, and honestly, each one tells a story about the kind of careful, developer-focused improvements that make Django such a joy to work with.

Let's start with the biggest one - and this is something that might actually change how you write queries. Nilesh Pahari tackled issue 36644, and this is one of those fixes that's going to make a lot of developers go "oh, finally!" Have you ever been frustrated when you call first() or last() on a queryset, and Django automatically adds primary key ordering even when you explicitly wanted no ordering? Well, that's history now.

Here's what changed: you can now call order_by() with no arguments to explicitly disable any ordering, and when you do that, first() and last() will actually respect your choice. Before this fix, Django would sneakily add primary key ordering anyway, which could mess with your performance or give you unexpected results. It's one of those changes that's technically small - we're talking about just a few lines in the query.py file - but the impact on developer experience is huge.

What I love about this fix is that it came with really thorough testing. Nilesh didn't just patch the obvious case - they made sure union queries work correctly too, which shows the kind of comprehensive thinking that keeps Django rock solid.

Speaking of solid, let's talk about our GIS improvements. JaeHyuck Sa fixed an issue that was probably causing headaches for anyone working with geographic data. The BaseGeometryWidget was throwing unhandled exceptions when it encountered invalid geometry data. Now it properly catches GDALExceptions and handles them gracefully. This is exactly the kind of defensive programming that makes your apps more robust in production.

And here's a perfect example of how the Django community takes care of the little things - SnippyCodes cleaned up the GeoDjango installation docs by removing references to libgeoip, which has been obsolete since Homebrew disabled it back in December. It's just a few lines in the documentation, but keeping the install process smooth and current? That matters so much for new developers getting started.

You know what strikes me about today's changes? They're all about respect - respect for developer intent, respect for error handling, and respect for the developer experience. When you say "no ordering," Django now listens. When your geometry data is malformed, Django handles it gracefully instead of crashing. When you're following install docs, they actually work.

These might not be flashy new features, but this is the kind of steady improvement that makes Django such a reliable choice for serious applications. Every queryset that performs better, every error that gets handled cleanly, every doc update that saves a developer from confusion - it all adds up to a better framework.

Today's focus: If you're working with querysets and performance matters to you, take a few minutes to audit your first() and last() calls. Ask yourself whether you really need that automatic primary key ordering. With this new change, you've got more control over your query performance than ever before.

And if you're doing any GIS work, this is a great time to review your error handling around geometry widgets. The framework's got your back now, but defensive coding is still a good habit.

That's a wrap on today's Django digest! Keep building amazing things, and remember - every commit, every test, every documentation improvement makes our community stronger. I'll catch you tomorrow for another dose of Django goodness. Until then, happy coding!