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

Sentry is indeed, and is open source and self-hostable: https://github.com/getsentry/sentry

It’s a pretty large app (I think >1M lines of Python). I ran a self hosted version for several years and found it performant and pretty easy to keep running and updated.

> stripe

Stripe has always been a Ruby-heavy company.