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.
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.