Some more things about Django I've been enjoying
ibobev
11 points
2 comments
July 22, 2026
Related Discussions
Found 5 related stories in 1333.3ms across 14,736 title embeddings via pgvector HNSW
- Python 3.15: features that didn't make the headlines rbanffy · 357 pts · May 21, 2026 · 50% similar
- PostgreSQL 19 features I'm excited about tianzhou · 34 pts · April 30, 2026 · 49% similar
- Things I've Done with AI shepherdjerred · 80 pts · March 09, 2026 · 45% similar
- Highlights from Git 2.54 ingve · 11 pts · April 20, 2026 · 45% similar
- With Claude: Less Coding, More Testing ingve · 22 pts · May 31, 2026 · 44% 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.