Some more things about Django I've been enjoying
ibobev
11 points
2 comments
July 22, 2026
Related Discussions
Found 5 related stories in 33.5ms across 3,370 title embeddings via pgvector HNSW
- Django is moving to an annual release cycle j4mie · 16 pts · August 10, 2026 · 55% similar
- Learning a few things about running SQLite surprisetalk · 206 pts · July 17, 2026 · 43% similar
- My thoughts on the Bun Rust rewrite kristoff_it · 673 pts · July 09, 2026 · 43% similar
- Blog about things you don't understand yet gfysfm · 64 pts · August 13, 2026 · 43% similar
- Java 27: What's New? loicmathieu · 52 pts · July 10, 2026 · 40% similar
Discussion Highlights (2 comments)
move-on-by
With any ORM, N+1 queries can be major performance problem. They can be a bit tricky to identify because individually the queries are fast, but when you execute N of them per request, it adds up. It’s worth looking at. You can write units tests that assert the number of actual SQL statements get executed for a given function. N+1 isn’t just a database issue either. I’ve seen N+1 at the cache level too with Redis. The cache layer supports ‘get_many’ and ‘set_many’. I haven’t stood up a ‘fresh’ Django app in ages, but some things I remember are worth looking at: * compression middleware like gzip. There is a big scary warning on this, but modern Django has mitigations in place * how your DB connections are managed and reuse them- I think Django even supports a DB connection pool these days * serve static assets directly - skip hitting Django for anything that isn’t dynamic
c0_0p_
I don't think the article mentioned it but adjusting how you configure the WSGI server can really affect performance too. It's also easy to accidentally make your DB queries sequentially or lazily. Using select_related is critical.