When Martin Odersky talks about scala as a scalable language choice, what he means is that the language itself is appropriate for:
- scripting stuff
- writing applications
- writing monster "enterprise" (for the want of a better word) applications
He is most certainly not referring to scalability from the perspective of performance!
The fact that he can claim that scala is as appropriate for quick'n'dirty scripting as it is for large-scale enterprise deployment is roughly as follows:
Scripting
Scala is great for scripting because its type inference and functional style make it both concise and great for slicing and dicing collections etc.
Applications
Scala is great for writing applications because it is a statically type checked language with some great features for working in both functional and imperative styles. Scala is compatible with Java and hence you can leverage an enormous ecosystem of libraries.
Enterprise Deployment
Scala compiles to bytecode and runs on the Java Virtual Machine, a stable system with great performance, when compared to (so-called) dynamically typed (i.e. untyped) languages. Again, the fact that it is statically typed means that refactoring is made much easier on large codebases.
There are many NoSQL solutions around, each one with its own strengths and weaknesses, so the following must be taken with a grain of salt.
But essentially, what many NoSQL databases do is rely on denormalization and try to optimize for the denormalized case. For instance, say you are reading a blog post together with its comments in a document-oriented database. Often, the comments will be saved together with the post itself. This means that it will be faster to retrieve all of them together, as they are stored in the same place and you do not have to perform a join.
Of course, you can do the same in SQL, and denormalizing is a common practice when one needs performance. It is just that many NoSQL solutions are engineered from the start to be always used this way. You then get the usual tradeoffs: for instance, adding a comment in the above example will be slower because you have to save the whole document with it. And once you have denormalized, you have to take care of preserving data integrity in your application.
Moreover, in many NoSQL solutions, it is impossible to do arbitrary joins, hence arbitrary queries. Some databases, like CouchDB, require you to think ahead of the queries you will need and prepare them inside the DB.
All in all, it boils down to expecting a denormalized schema and optimizing reads for that situation, and this works well for data that is not highly relational and that requires much more reads than writes.
Best Answer
noSQL databases give up a massive amount of functionality that a SQL database gives you by it's very nature.
Things like automatic enforcement of referential integrity, transactions, etc. These are all things that are very handy to have for some problems, and which require some interesting techniques to scale outside of a single server (think about what happens if you need to lock two tables for an atomic transaction, and they are on different servers!).
noSQL databases don't have all that. If you need that stuff, you need to do it yourself, but if you DON'T need it (and there are a lot of applications that don't), then boy howdy are you in luck. The DB doesn't have to do all of these complex operations and locking across much of the dataset, so it's really easy to partition the thing across many servers/disks/whatever and have it work really fast.