Well, it scales much better than it may seem. The main thing is you have postgres in its core. And you would probably have postgres anyway as this is one of the best sql dbs and number one choice for a lot of developers for years now actually.
So this part would scale identical to some “custom infra”.

Well if requirements change, you need to change your DB schema and business logic anyway right? So what’s the difference if it is located in sb postges or other postgres. Or if it is deployed to sb functions, or vercel functions.

Don’t forget that supabase is open source and you can always migrate or spin up additional instances both yourself or hosted. This is extremely easy and there are docs about migration from and to supabase.

Other services, well, it depends here, some may scale better than the others. But because of decoupling, you can always replace some components with something built in-house and optimized for your specific scenario.

But what is really important is that you would only find out what “specific scenario” is, when you will face the actual load profile, this is almost impossible to predict.

Having the working solution quickly will buy you time and money literally to understand your users, to pivot your product, understand your users better, and find all potential bottlenecks. Then you will be able to scale vertically or splitting to shards, creating “dedicated” projects for huge customers, or find other temporary solutions. And take this time to work precisely on your real bottlenecks by contributing to these services or rebuilding some of its features with respect to your usecase.

Lastly, even though Sb can scale pretty well. One of the greatest advices from yc, and it works not only in startups: “do things that don’t scale”.

And you know, you will probably have a dozen of great engineers who will find out tens of ways to upgrade your infra and tackle the scaling problem if you hit the vertical scaling limit ;)