My team migrated a service handling >1.6k req/s at peak time, from Scala (Finatra), to Python (Django). Same number of servers (3x c5.large), just higher CPU utilization (from ~15% to 70%).

Scala was great, but unfortunately it made it difficult to onboard new team members into the project, so development suffered. Also the rest of our stack is mostly Python, so we couldn't use a lot of the common tooling, and libraries we had built for other projects.

We migrated it within a month, and it's been running for almost a year without issues.

At some point the service even recorded 3k+ req/s at ~200ms 99p latency. Yeah, maybe not Google scale, but more than enough for 99% of the businesses out there.

This service handles about 2.5 billion requests per month from one AWS region. We're a small team, and that's only one of the services we support. Which is great because we don't need to spend all of our time optimizing it.

Notwithstanding this (that Python will scale), Python will force you to scale horizontally a lot earlier than something like Rust. In mid-2013, NewsBlur was using 48 servers to run its Python/Django stack. The workload was reasonably precisely declared (and I could grudgingly see why it used so many servers for its stack), so I was able to run the numbers and confidently concluded that something reasonably efficient (which for me would now mean Rust) could have handled the same workload on one equivalent server, though not with a great deal of headroom, and further vertical scaling might have started running into I/O limitations. But for a one-man thing, I know I would prefer to use a single server as long as convenient, and a 98% reduction in hosting bill is very significant (though that’s a moderately extreme case, and I imagine smaller parts of the code could have been rewritten in a language like Rust to get a meaningful fraction of that resource usage reduction).

Or, alternatively, if most of your heavy-lifting is already done in the database layer there's less work for Python to do.