Ok Ok Ok... first off, I apologize for the sliiightly misleading subject line. But, I thought I'd try to draw some attention and see if I could get some discussion going (hopefully no flames though!).
1) "At this point in time there's no facility in Rails to talk to more than one database at a time."
I have seen Rails deployments that use multiple databases, theres an illustration of one on the Ruby on Rails site for a german web community.
Basically there is two databases, each is attached to a farm of Rails Pizza boxes. Each Pizza box can only ever see one DB, but the DBs increment their PKs in 2s (one is even the other odd), so that they can periodically replicate/merge their data sets.
In principle you could use multiple DBs and scale horizontally, but replication overhead will probably eat into you very quickly.
2) "setting up multiple read-only slave databases [is not a quick fix to implement]"
3) Ruby + Rails' syntactical sugar = slow
Point #3 is pretty well known, the solutions always mentioned before is scale out. However, Alex says that they can't because of 1 & 2. I've been under the impression (and still am) that doing 1 & 2 really isn't that hard.
Well there are different options for 2. I am quite sure that you actually spend lots of money on your DB to achieve it.
He did say or imply though that scaling out incurs additional DB overhead per Rails instance. Which implies an optimal ratio between DBs & Rails instances.
So, the question is, what to do if you have a rails app and are in twitters place?
Pretty much what he is doing already. But then, its not like scaling is easy in the first place.
You have to ask yourself though - Twitter got up and running in ~ 9-12 months or so? In a Java/.NET version would he even be in production by now? How would the PHP equivalent fare?
