They both hit the same challenges. The bottleneck with any web application is pretty much always the database, especially SQL ones where replication and sharding is not as easy as some other tech like MongoDB and ElasticSearch.

Both kbin and Lemmy use PostgreSQL, so they’ll both hit similar bottlenecks.

Lemmy has the advantage of processing much faster thanks to its Rust backend, requiring less CPU, but PHP is also very easy to scale up to add more server and more compute to it. PHP has some advantages despite its reputation, in that it’s pretty hard to have memory leaks like Lemmy experienced recently, because the whole process resets at a configurable amount of requests, and on the PHP side, each request is independent and starts over from scratch, making it hard to accumulate in-process state that doesn’t get wiped out after each request. It also indirectly forces you to rely on external cache and queue services for synchronization, which can help prevent some gotchas that long running servers in Rust/C#/Go/NodeJS would. In a single process it’s easy to turn to global state and hit gotchas when you have it running on two different servers.

But functionally, they’re all capable of roughly the same, as the bottleneck will still be the database. Scaling databases is not easy, although not necessarily that crazy hard either.