Well, I'd start with two definitions of scale, and one of the definitions does not matter.

Firstly, "Ok, but does it scale?" kind of a definition. The scale used in this context is more often related to the number of requests per second. Performance kind of scale, or throughput kind of scale. I'd say even data size scale.

How many users can be served at a single point in time? Could we go from 0 to 20M DAU without rewriting the entire application? Well, the answer for that kind of scale is usually "let's use NoSQL", at least it was so like 10 years ago with the rise of NoSQL solutions.

However, the reality is that most applications are not going to hit such scales. Even more, most of the applications are not even meant to be used at that scale. And those which are meant are probably not going to reach these numbers without refactoring anyway. The success of software is not defined by the technology it uses.

There is another kind of scale: the complexity of the product. This scale also grows with the growth of product. It is the complexity of the data model for the product that also scales.. And SQL with its data normalization takes care of it. You spend a little more time to shape data more strictly but it makes your development and maintenance a bit easier. So for this kind of scale SQL is more scalable.

I said that one definition of scale does not matter. Ok, it is for you to decide which one does not matter. So, let's say you are writing a software product for an enterprise. You have a contract and terms, the app is not going to be used by millions of users worldwide, it is meant to be used in a contained environment. There will be a lot of analytics data generated by the app. In this case, performance scale does not matter; complexity scale does. It is a perfect match for SQL. Good for maintenance, easy to connect to analytics tools.

If you are a sole developer doing some customer facing product. What should you choose? I'd say pick what you are more comfortable with. The tools you know better. In that case it is not about optimising for performance or usage or maintenance. You are optimising for your development experience. So the thing that matter is what is easier for you. If you have been with fullstack frameworks, ORM and SQL, then just do that. You may not be in a situation when you need performance scale. But if you choose what you are good with then the chance of reaching such scale is bigger. Just because you'll be more effective with your tool.

There are, of course, a lot more things to consider between SQL and NoSQL. And there are different implementations of both. The distinction between them is not that straightforward nowadays. But if you are in the "Does it scale" situation, then think about what kind of scalability is more relevant for you.