[rademi]

You can shard RDBMS relatively easily -- basically you wind up pushing a part of your database structure into your clients, so your clients can decide which shard to use.

The cost, though, is that you wind up having a difficult time doing some things that MongoDB can't do. (For example: Renormalizing your database... Does that even mean anything for MongoDB?)

There's something to be said, of course, for simplifying your design. But it's probably a good idea also to make sure your design reflects your requirements.

[rgnitz]

Indeed you can distribute data to multiple independent RDBMS, but balancing when new nodes are added is probably a manual process (or a lot of custom code) that is likely to require downtime. To avoid downtime, your application would need to write to both chunks while it is balancing/migrating (and then delete the old data/chunks once it is migrated to a the RDBMS). Essentially, you would need to write what is already in MongoDB.

You would also have to write a parallel query engine.

I too am a fan of simple designs, but I think rolling your own sharding on top of a RDBMS would likely be a massive chunk of time.

There are really expensive commercial products working on horizontally scaling RDBMS... but personally, I prefer open source and document oriented databases :-)