* You only get the GAE database, no RDBMS, not even alternate nosql things like Mongo. * Doing geo stuff on GAE is pretty infeasible. * You can't run other co

* You only get the GAE database, no RDBMS, not even alternate nosql things like Mongo. * Doing geo stuff on GAE is pretty infeasible. * You can't run other commands, e.g., shell out to git. * You can't connect to any services except HTTP (on port 80/443). * While you can use the database instead of a filesystem most of the time, it's often harder. Even simple things like using a library that does file-based caching adds challenges to code reuse on GAE. * There are no C-based libraries on GAE, including things like lxml, image processing libraries, etc. GAE slowly adds new GAE-specific libraries for some of those operations, but slowly and inconsistently. Often an app won't need these things, but maybe at some point in the future it will -- with GAE you are kind of stuck at that point, or you have to setup external services to augment your core GAE app (removing a lot of the operational simplicity of GAE). And because Django Zoom uses individual virtual servers there's no point at which you can't somehow accomplish what you want to accomplish, even if it's not something directly baked into the service. In practice it's extremely uncommon to develop an application then move to GAE -- people always develop for GAE from the beginning.