Any justification for separate database

Question

Since the days of CiviCRM as a standalone project are long passed, is there any reason, in 2016, to have a separate database for Drupal and one for CiviCRM? If so, what is the compelling reason? For the record, I only see downsides, not the least of which is backup and restore should disaster strike. I've just taken over the care and feeding of an existing site where separate databases were used in the setup. The customer used the backup_migrate module to do regular database backups and, you guessed it, only the Drupal DB was actually getting backed up.

Thanks for your insight.

-- Marcel

Answer 1

To add to Erik's, here are three advantages to separating the databases:

1) Upgrades. When we are working to upgrade Civi, I know that the website side of the house is largely unaffected (not completely unaffected, but mostly), and if something in the upgrade goes awry, I'm only having to deal with the Civi side of things (especially in the event of downtime).

2) Restoring backups. Should you need to restore a backup of your website (like we did last year), you are only losing the web changes made since the backup, not the Civi changes as well. The same is also true if you need to restore the Civi backup -- you then don't lose the website changes made since the restoration point.

3) Multi-site installations. See the documentation here: Multi Site Installations

Answer 2

My standard practice is still to have them separately simply because I prefer the overview as a developer. And obviously you have to make sure the backup is OK, but if they never checked that (or tested it) I would see that as a bigger issue than having it in one database :-)

Answer 3

I use separate database whenever possible, for a few reasons, many of which Allen already covered. In addition, I am often responsible for migrating data to a new CiviCRM installation while a coworker (or another dev shop) is responsible for CMS implementation. This allows me to give frequent updates to the client on a test server without coordinating with another developer.

Also:

• I like to grant the minimal permissions needed on a per-database basis. CiviCRM requires more permissions out of the box than Drupal.
• I haven't really heard a compelling argument in favor of doing it as a single database. It's unfortunate that in your case the CiviCRM database wasn't backed up by backup_migrate - but backup_migrate is easy enough to configure to back up both databases.

Answer 4

One more thing further to the answers so far: moving to a different CMS. If, for whatever reason, you want/need to move civiCRM to a different CMS this is quite simple if the databases are separate. I've done it, so don't say it will never happen.