Since the R-Pi is for education first and foremost, this is a good idea for learning the concepts of a multi-processor architecture, but, the R-Pi's hardware configuration is overkill on a per-processor level in the real world, vs. the architecture of the HP designed-to-purpose product. Processors should communicate over an interprocessor speed bus (as in the HP product), not 100 Mbps Ethernet, which will be a severe internal bottleneck. As has already been pointed out, the 100 Mbps Ethernet on a "master" node will also be a severe external bottleneck, as would a single-instance database running on one node. A truly distributed database running in a failover mode across multiple processors gets very complicated very quickly, especially if the users will be allowed to create database records, as locking and unlocking database elements at various levels of granularity within the database comes into play. The Linuxen that will run on the R-Pi (initially) are oriented toward single-processor operation - to do this right would really require something like a Unix Mach implementation, such as that used by Apple's OS X, some versions of BSD, and the server versions of Linuxen (e.g., Fedora Server). It might be possible to use one of the Beowulf cluster packages, but, that's really deisgned more for massively-parallel mathematical computation, and each R-Pi's GPU is already a screaming 24 GFLOPS floating-point powerhouse, internally (it could beat the pants off single-processor supercomputers of 15 ~ 20 years ago).
However, not to rain too hard on your parade, you would learn a great deal by implementing this on a handful of R-Pi's. Until the one-board-per-person rule is lifted, get some friends also lucky enough to receive their boards interested to work on it together and test what happens as their R-Pi's are inserted and removed from the network, literally as they take their boards home with them. You'll learn about failover, dynamic allocation of resources, resource balancing issues among multiple processors, the difficulties of detecting infinite circular logic loops, deadly embrace when more than one processor wants to access the same resource and the random back-off schemes for resolving this, shifting of master/slave tasks when various nodes fail or become disconnected from the network, etc.
Most of all, have fun and let us know what you're able to cobble together, if any of us ever receives our boards
The best things in life aren't things ... but, a Pi comes pretty darned close!
"Education is not the filling of a pail, but the lighting of a fire." -- W.B. Yeats
In theory, theory & practice are the same - in practice, they aren't!!!