The rule of thumb I have always been told is that you can push MySql to ~200 GB total and between 99.9% and 99.99% availability (between 1 and 9 hours of downtime per year). Your milage might vary, but these are probably the right orders of magnitude. There is also an iops limit but that's harder to put a clear limit on because it's workload dependent.
If you need more storage, availability, or iops, the current recommendations are shared relational stored or NoSql.
Sharding relational databases means instead of turning on 1 MySql machine, you turn on 16 MySql machines and store 1/16th of the data on each machine. It only allow queries patterns that can be responded to by a single shard (so if you are only doing queries on a per user basis, your golden, otherwise, not so much) and require that your hottest shards (e.g. most active users) should only be a few orders of magnitude larger than your coldest (Justin Bieber probably needs his own machines at Twitter because he has so many users). There are ways to get around this, but they are tricky and will require a lot of developer time.
With NoSql (riak, cassandra, dynamo, etc.), you have to give up many features that make developers lives easier in order to scale beyond a single machine. Each flavor has it's own set of tradeoffs, but the biggest problem is that you loose (1) committing multiple rows at the same time (atomic commit) and (2) ensuring queries don't overlap (isolation).
Spanner offers an alternative where the developer (for the most part) doesn't have to know that her data lives on multiple different machines. It gives you 99.999% availability and theoretically unlimited scaling to any size, with an API that is still relatively developer friendly (compared with NoSql or Shared Sql). One cost here is latency / performance. You need to write to multiple computers across the world so write speed will be bounded at a minimum by the speed of light between those datacenters.
Short answer, there are a lot of companies that could benefit from a system like this. It could give higher availability to a small Sql dataset or stronger guarantees to a current large NoSql database. There is even an argument to be made that the majority of problems companies face today are best solved with this type of system and relational or NoSql optimized workloads are the exception, not the rule.
If you need more storage, availability, or iops, the current recommendations are shared relational stored or NoSql.
Sharding relational databases means instead of turning on 1 MySql machine, you turn on 16 MySql machines and store 1/16th of the data on each machine. It only allow queries patterns that can be responded to by a single shard (so if you are only doing queries on a per user basis, your golden, otherwise, not so much) and require that your hottest shards (e.g. most active users) should only be a few orders of magnitude larger than your coldest (Justin Bieber probably needs his own machines at Twitter because he has so many users). There are ways to get around this, but they are tricky and will require a lot of developer time.
With NoSql (riak, cassandra, dynamo, etc.), you have to give up many features that make developers lives easier in order to scale beyond a single machine. Each flavor has it's own set of tradeoffs, but the biggest problem is that you loose (1) committing multiple rows at the same time (atomic commit) and (2) ensuring queries don't overlap (isolation).
Spanner offers an alternative where the developer (for the most part) doesn't have to know that her data lives on multiple different machines. It gives you 99.999% availability and theoretically unlimited scaling to any size, with an API that is still relatively developer friendly (compared with NoSql or Shared Sql). One cost here is latency / performance. You need to write to multiple computers across the world so write speed will be bounded at a minimum by the speed of light between those datacenters.
Short answer, there are a lot of companies that could benefit from a system like this. It could give higher availability to a small Sql dataset or stronger guarantees to a current large NoSql database. There is even an argument to be made that the majority of problems companies face today are best solved with this type of system and relational or NoSql optimized workloads are the exception, not the rule.