The tradeoff of master to master replication limits you to CRDTs, append only logs and manual merging of conflicts by the end user. Alternatively if dataloss is an acceptable tradeoff you can also use a last write wins strategy.
Sharding is basically having one isolated "database" per X (User, location, etc) but the tradeoff is you can't have transactions across two databases.
Document databases usually do both. Each document is it's own tiny database with atomic updates which then can be distributed over the cluster and they support multi master replication for availability/automatic failover.
We've created a library at Citus to make rails sharding turn-key, activerecord-multi-tenant. We have a Django one in the works, if you want to take a look and give us any feedback on it please drop us a note. From what I've seen hibernate has some out of the box support, but we only have a few customers leveraging it so not as familiar with it.
http://docs.doctrine-project.org/projects/doctrine-dbal/en/l...
As with all decisions, there are tradeoffs. For a little more up-front complexity and a tiny nominal performance hit, this allows maintenance, encryption, non-uniform storage paradigms to suit individual ledgers, rolling upgrades, storage location migration, and other cool stuff which is typically painful with traditional all-or-nothing RDBMS architectures.
A flip-side view is that, in many cases, if you really want to trust your data (not your database), then you want to be doing this stuff to a large extent anyway... which means that, basically, it's just enforcing good practices that should have already been present.
Complexity and per-TX latency increases, but for that you get maintainability and a great deal of flexibility. Nothing is free... take your pick!
The one solution that was mentioned, Facebook's TAO, isn't actually really a database; it's a cache, which means that it doesn't really have to deal with sharding in the way that persistent stores do. And it doesn't really shard at all; it basically stores a complete copy of the world's social graph in every region, which it can just populate from that region's MySQL replicas. (It's amazing the things you can do when you can be eventually consistent.)
(From what I recall, the main social network's MySQL also isn't really sharded by graph in any fancy way; it's basically "just" hash-sharded by entity ID.)
