Reading between the lines, this shows that App Engine is a growing & responsive project, and makes me less nervous about building on it.

Look at this from the perspective of Google Apps corporate users. Imagine that the IT intern has just completed the corporate cafeteria's lunch menu system, and it's time to deploy it. While it's then least significant application the IT department manages, there's still a high fixed labor cost for infrastructure roll-out and management. The DBA must provision instances across dev, QA, and production environments. Onto which servers will the application be deployed? Must they be procured? Even if the lunch menu app is deployed on a VM instance, that OS image still requires security patches and other upgrades. The cost of deploying the intern's work likely exceeds his/her salary for the summer.

With SQL on AppEngine, corporate developers can build apps like this without learning how to use NoSQL for persistence. Even if GAE's SQL doesn't allow scale-out sufficient for SaaS vendors and such, it will fill an important niche in Google's apparent goal of moving corps onto their cloud. As another commenter here suggested, the bar for perf/scale in many cases may be no higher than that provided by a MSAccess DB hosted on a Windows fileshare.

We are living weird times. Multitasking, copy/paste, SQL support, these things are old, but still newsworthy when added to new platforms/services.

This could help out those who are building projects using Django &/or Django-nonrel.

So long as the performance is reasonable, this will go a long way towards removing lock-in barriers with AppEngine.

Hopefully this is the real deal and not an abstraction on the current datastore. When using the datastore in a relational way, you get some pretty horrid performance.

I rather got the feeling that the datastore was much better for certain kinds of things than SQL. However, unless you are an expert in both SQL and the use of BigTable, how would you know when to use the one over the other? Okay, so obviously SQL is 'designed' to be good at transactions (whether it is or not is an exercise for the readers), and BigTable is really good for fuzzy search.

I'm guessing that SQL is actually going to be more useful for anyone doing e-commerce (hence transactions) or anyone with familiarity with traditional SQL based persistence (even - shock horror - JDBC).

SQL is bland, BigTable is sexy. But another word for bland is mature...

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.

Google should buy a SQL engine like Postgres now that mySQL is in oracle's hands. People will need SQL databases till the end of times, and coupled with BigTable that can be a killer in the database space.