Assaf Arkin: if anything I wrote sounds vaguely familiar because you somehow managed to dumb your RDBMS into storing structured data in BLOBs, added versions and timestamps on all records, grappled with minimizing transactions and locks, denormalized data like thereís no tomorrow, or relied too much on a message queue, then time to rethink. Are you using a hammer to polish your china? (Tip: not a good idea, invest in soft cloth)
I also didn’t understand the fuss about google’s app engine and shared the view that it looked like “The World’s Worst Webhost“. My current webhost lets me run ruby, perl, php and python with either mysql or postgres, so why would I want to limit myself to python and some proprietary, lock-in database. The answer is, of course, scale.
And so here is the dilemma. If you are developing a new web application from scratch what do you do if you think / hope that one day you will be wildly successful? There is the flickr / facebook / myspace path i.e. use a single relational database till it breaks, then use master / slave and then shard (gory details for myspace) and now there is the google app engine path i.e. build the application from the start in a way that is guaranteed to scale out with no herculean efforts.
This is not an easy choice. The problem with the google path is that their datastore has no joins, limited transaction support and some random query limitations. Now, I have never built an application with those limitations, but I would guess that it takes longer to build and requires a whole new way of thinking.
The google app engine path seems difficult to justify for a new app. It’s built on the premise that the app will be wildly successful and most web apps aren’t. Justifying the additional upfront expense to investors / management won’t be easy and given that many big names have already successfully traversed the other path, it may be better to start by choosing one of the world’s better webhosters and only invest in scaling the db when the money starts rolling in.