I believe (in practice if not theory) it is common to handle db schema updates separately and to run both systems off the same database. This way the data only lives in one location but you get to run two slightly different app servers/frontends on top of it. You are then more careful with database changes. This sounds like a pain in the arse but a lot of people seem to be able to run with it without it causing a lot of additional overhead having to schedule your db changes to go out before your dependant code changes.

Copy DB from live [blue] to staging [green], then run migrations and test. Do this several times. This should give you confidence that the migrations behave as intended before you flip from blue to green for production & run the migrations for real. If you have "big data" you can use schemaless migrations, for example never rename a column, instead add a new column, update the app to deal with both columns, then in a subsequent update remove the old column. You can also avoid migrations [use mongo instead of relational DB, for example]. I recommend Fowler's "DB Refactoring" book for further reading. http://martinfowler.com/books/refactoringDatabases.html

Personally I keep the database out of the equation, ala 12 Factor.

The database when treated as a unique exception allows you to just get on with developing robust infrastructure.

However for this to work you need to keep code off the database and treat database changes as migrations not blue/green deploys.

I can't say this enough, treat the database as an exception, keep it clean without code on it and with 'soft' schemas (ones that tolerate minor changes well) - then you can do b/g deploys easily.

Also let someone else host the DB where possible (or the same cloud infrastructure of course), it's just not worth the pain.

Yes. Especially if you're using one of the systems as a failover or you're running them as a normally active-active configuration. You want DB replication, but you also want to be able to take down a blue or green, apply DB updates, be able to independently access blue or green to check out your changes, then roll the world over the upgrade leg, then do the same work on the other side, check it out, and then make it available.

Alternating on blue / green as the 'live' side works, too.

It's complicated and time consuming, but one way to do it is to never modify a column, add new ones and use trigger to copy values from one to the next. Only delete two deploys later.