[seabrookmx]

In Instagram's case, they do not use the ORM or Admin, and have an internal fork of the request handling/middleware stack that is 100% async (before the recent async bits were added to Django)[1].

It's great that Django's API design allowed them to move this way easily, but they aren't actually using Django in the traditional sense because it can't handle their scale.

I've found that with the Django ORM and DRF especially, it's very easy to create a poorly performing app by following the established patterns (N+1 queries being a huge problem created by DRF serializers). You need to be extremely diligent to create something performant in this ecosystem. Not every dev team has Armin Ronacher :P

Where I work we found this exhausting, and moved on to FastAPI and ASP.NET. We make our queries much more explicit using tools like Dapper, and now a senior engineer can have a much better idea how a particular route will perform just by reading the code (obviously, we still do some profiling).

[1]: https://djangochat.com/episodes/django-instagram-carl-meyer

[megaman821]

It looks like the next release of Django will take seriious strides to solve a lot of the n+1 headaches, https://docs.djangoproject.com/en/dev/releases/6.1/#model-fi....

Also, I doubt solving Instagram-level scale issues is on the top ten list of concerns for this project. Just getting something out there and gaining users is way more important than solving far future scaling issues.

[seabrookmx]

Oh I agree 100%. Use the right tool for the job. I'm just saying, the "<hyperscaler> uses <framework>" logic is rarely useful to justify anything.