A simple, non-computer example. You are checking people in at a conference registration booth. You have people with last names A-M in line one and N-Z in line

A simple, non-computer example. You are checking people in at a conference registration booth. You have people with last names A-M in line one and N-Z in line two. You have just sharded the registration forms by last name. The Pro is that it's a lot faster to get people registered. The person at the desk has to seek between roughly half the records. The Con is that the person at the desk can't easily/elegantly get a record not in their grouping. For example, a couple comes up where they have different last names (John Jones and Jane Smith). You can't check them both in without bothering the person next to you and making the process slightly cludgy. How does this apply to databases? Well, if you have a users table that is sharded, some users are in DB1 and others are in DB2. You can't simply join across the different servers. That's the big con to sharding. You lose the ability to join. There are things you can do, but they're cludgy. The good thing to take away from this is that, unlike the conference check-in, databases are really good and fast. You don't need to shard as quickly as you do with humans. When you start getting a high level of concurrent activity, you can add replication. Once you've exhausted that, only then should you think about sharding. Without sharding, you can create large sites, but you'll get to a point where you need to start thinking about it - you're not at that point (not that I am). Twitter is at that point and handling it poorly. Really, if you get that big, you'll have the money to hire someone who knows what they're doing.