Nobody wants it. It would be great if we could just run an arbitrarily large RDBMS as one node.<p>Sadly, hardware has limits, especially if you use cheap(er) virtual hardware. OTOH you can see Stackoverflow pulling just this trick: a single colossal SQL server handles most of the load [1]. They, of course, run two DB servers because they need a hot spare.<p>[1]: <a href="http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html" rel="nofollow">http://highscalability.com/blog/2011/3/3/stack-overflow-arch...</a>
Scaling horizontally or vertically, on-premise or with cloud service provider is always debatable.
IMHO for the scalability topic especially in the internet industry, China or Indian companies may have more say about it thanks to the largest population.<p>Searching through the mentioned TiDB, it's quite interesting to find through its affiliated site <a href="https://ossinsight.io/analyze/pingcap/tidb" rel="nofollow">https://ossinsight.io/analyze/pingcap/tidb</a>, that the popularity (stargazer) seems pretty high in China.
The US stars is not bad, comparable to Mongo's.<p>Honestly I've not heard about it much. How much of the load these databases can support up to, with a single cluster ?
I don’t think sharding is a big issue for application development. It adds overhead to devops/sre teams though, especially in the case of resharding. I have seen worst issues and overhead to dev team caused by bad table partitioning schemes, not sharding.<p>Imo the biggest challenge of rdbms in modern saas is hybrid (oltp + olap) query pattern. Any cloud managed service that is going to nail this in a costly efficient manner will become the next mainstream thing.