[boulos]

For your first question (playing with Cloud SQL) you've got two options. Directly interact with Cloud SQL from your laptop or like you said have a "development MySQL" separate from prod / staging.

Pointing at your Cloud SQL instance (maybe using a staging or development database) can be done in settings.py. The switch between modes let's you specify the IP address for your Cloud SQL instance when you're not on App Engine (which uses a special UNIX domain socket). We also recommend you connect over SSL when doing so outside (see more at the link I provided, or search for cloud sql ssl).

Having a local environment for MySQL is also easy enough depending on your box, but has the usual difficulty of needing to have a good test suite / being populated with useful data. I think it's worthwhile if you can pull it off, but I've seen companies big and small decide its not worth it (and instead use a separate table or database on the same server, maybe as a different user as another line of "don't screw up prod").

Finally, the interaction between Django's development server and the App Engine one isn't great. My response was intended to remind people that if you're not looking to use App Engine specific APIs you really can just get going and almost not notice. But you should be able to run your migrations speaking to Cloud SQL remotely without needing to import say Task Queues. So my workflow was to use manage.py for things like that, while using the dev_appserver when I actually needed to emulate App Engine (as opposed to the Django runserver command).

Does that help?

Edit: I forgot to add that we're working on decoupling the "emulation" of our services so that this kind of interop works better. See https://cloud.google.com/sdk/gcloud/reference/beta/emulators... for Datastore and PubSub (and more on the way).