[vsiva68]

Another way of saying the same thing is that GAE is perfectly fine if you know all the requirements of your app before you build it. In a perfect world, you know exactly what you want to build, everything you want is available with GAE, then you go build it and it scales nicely.

In the real world however, requirements change: * You come up with a new idea that requires a certain library. Chances are, the library won't work on GAE out of the box. * You find out that you need to change your schema. It is pretty hard to update to the new schema while keeping everything in sync.

Finally, you pay the Google cost. When Google implements a new feature, they spend enormous time making sure that it scales well. They need to do so since they could be looking at millions of users on day 1. Most of us however, are looking to build something as cheap as we can, not knowing whether anyone is going to bother to look at it. However, you have to do the same performance optimizations that Google has to do so that your app scales. Chances are, it will be wasted effort - unless your objective is to just learn. I find it funny that GAE goes completely against the rule that "Premature Optimization is the root of all evil". Yes, you should think about your application's scalability. But your bigger problem should be about finding traction, and being able to react fast, not optimize for millions of views.

[bane]

If I understand correctly then, it would appear that GAE may be poor for applications that require heavy computation on the server side (say, a facebook style graph, crawling and computing various metrics on it) but great for serving tons of dynamic pages?