Yes, it is wise to do that. If you don't want the overhead of running your own SQL instance, you definitely don't want the overhead of running it on kubernetes; it's quite tricky (but the addition of StatefulSets in 1.5 has made it easier).

If you're running a CloudSQL instance, you can use a sidecar container to manage proxying the connection to the database: https://github.com/GoogleCloudPlatform/cloudsql-proxy

"The Cloud SQL Proxy allows a user with the appropriate permissions to connect to a Second Generation Cloud SQL database without having to deal with IP whitelisting or SSL certificates manually."

I've been having rather significant latency going through the proxy (MySQL Cloud SQL) - has anyone else experienced similar?

> Some say it is not wise to use Docker for DB

I think what most people mean when they say that is "don't put the DB in Docker", so don't use Docker to host Postgres. Just because your app is hosted by Docker doesn't make it more or less wise to connect to a database. It just depends on if you need a database or not.

This is exactly what I plan to do. Not really because of any specific issue with Docker, it's just that databases have very different lifecycles than your typical container.