Some database heavy applications were not designed with sharding/scaling out in mind. Rewriting an entire application to do so is not a trivial task and takes a

Some database heavy applications were not designed with sharding/scaling out in mind. Rewriting an entire application to do so is not a trivial task and takes away the focus of an entire company and development team during the process of such a major endeavor. At my last company we had this problem. We had a simple application for tracking inventory that morphed in to a CRM with tons of data from emails, notes, etc. Database grew to be terabytes in size. Using fusion-io cards and replicating to read only databases was required to keep us going and it worked. We had to keep buying bigger iron. A database server with 2TB of RAM! At my new company, Stackify (http://www.stackify.com http://www.stackify.com), I made sure we gave each client their own database so we knew we could scale out from the beginning. Now we manage over 1000 SQL databases and that has its own set of challenges. We use SQL Azure so that makes it all pretty simple thanks to their new elastic pool features. Versioning SQL schemas and using tools from red gate have helped us keep our sanity.