[amix]

If you plan to create a popular product that handles tons of data and tons of users, then include sharding as soon as possible. Bolting sharding on after you have lots of data, lots of code, lots of traffic and lots of users is a nightmare and worst-case scenario.

You can postpone it thought if you are unsure how popular your product will become. If you do postpone it, then be sure your joins are "sane" - normally, you don't really do joins in a sharded environment as data is located on different databases, so you will do yourself a major favor in not doing joins that will force you to re-model your data when you switch to sharding.

And in a sharded environment you also copy things around :)

[aaronblohowiak]

I like to abstract data access from the implementation of its storage, so making changes to the storage methodology shouldn't/won't require substantial changes to business or application logic. Keeping the separation clear is more difficult for some people than others. One of the problems with the route you are suggesting is that people don't know the future. Eliminate bottlenecks as they start to come up, and don't tightly couple unrelated concerns.