Nice feature, but not super important for new projects. I suppose it will make porting some existing projects over.
I didn't remember seeing SQL on the roadmap however so I had another look ( http://code.google.com/appengine/docs/roadmap.html ) and I'm very excited to see it as been revised with a few awesome enhancements. I've had several projects I wanted to try on app engine which were impractical because of GAE limitations like no full text search, no programmatic access to blobstore, no bulk export/backup, no mapreduce. The future is looking a lot brighter for GAE.
At the risk of re-hashing a number of previous discussions, GQL appears limited when compared to SQL because Google's database is designed to scale to extremely large datasets and massive numbers of concurrent users. The features that are missing were removed intentionally because they don't scale. If you can re-think your database use to be consistent with this new paradigm, then you'll have a much more scaleable app when you're done.
The end goal for every app doesn't have to be scaling on the order that GAE's original design provides. People have lived for years creating apps that use Excel or Access as a datastore.
Being able to use SQL on GAE will allow more widespread use of GAE for things besides "the next twitter".
The flip-side is that anyone who needs to do reporting, aggregation, etc. is going to spend a lot of time reinventing stock behaviour while their competitors focus on building new features. Those competitors are more likely to get to the point where they have the relative luxury of deciding how to handle large numbers of users because they actually have them.
If the first user waits 2 seconds per response and the millionth user waits 2 seconds per response, that does indeed meet one definition of scaling. The problem is you aren’t going to find a million users willing to wait that long. So why punish the first user?
It is extremely limited. I just accepted this as a result of the limitations of a distributed datastore and disqualified GAE as a candidate for any query intensive apps I want to do.
The other limitations I listed didn't seem to have architectural causes so I find them more frustrating.
I was halfway a weekend project to find out GAE can't do LIKE-statements or an equivalent thereof, only with some hacking this is sort of possible. Moved the project to RoR and got it working in no time.
Another project I had couldn't be done because the datastore was to slow. I love GAE, and use it for quite some little projects but you have to know its limitations. SQL (and hopefully the speed that comes with it) are certainly a step in the right direction.
It's a very big deal for new projects, if it means Django will run out of the box. GAE is a pretty awesome platform for small projects, a clear migration path in/out will make it much more attractive for bigger projects.
I didn't remember seeing SQL on the roadmap however so I had another look ( http://code.google.com/appengine/docs/roadmap.html ) and I'm very excited to see it as been revised with a few awesome enhancements. I've had several projects I wanted to try on app engine which were impractical because of GAE limitations like no full text search, no programmatic access to blobstore, no bulk export/backup, no mapreduce. The future is looking a lot brighter for GAE.