Answers.Body: <p>To add to Erik's, here are three advantages to separating the databases:</p>
  
  <p><strong>1) Upgrades.</strong>  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).</p>
  
  <p><strong>2) Restoring backups.</strong>  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.</p>
  
  <p><strong>3) Multi-site installations.</strong> See the documentation here: <a href="https://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation">Multi Site Installations</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-03T18:47:36.313Z
Answers.LastActivityDate: 2016-02-12T17:38:29.347Z
Answers.LastEditDate: 2016-02-12T17:38:29.347Z
Answers.UserDisplayName: Allen Hutchison
Answers.Body: <p>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 :-)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-03T18:44:03.697Z
Answers.LastActivityDate: 2016-02-03T18:44:03.697Z
Answers.UserDisplayName: ErikH - CiviCooP
Answers.Body: <p>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.</p>
  
  <p>Also:</p>
  
  <ul>
  <li>I like to grant the minimal permissions needed on a per-database basis.  CiviCRM requires more permissions out of the box than Drupal.</li>
  <li>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.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-13T20:43:27.683Z
Answers.LastActivityDate: 2016-02-13T20:43:27.683Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T23:50:46.693Z
Answers.LastActivityDate: 2016-05-18T23:50:46.693Z
Answers.UserDisplayName: Josh
Body: <p>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.</p>
  
  <p>Thanks for your insight.</p>
  
  <p>-- Marcel</p>
  
Tags: <best-practice><backups><sysadmin>
Title: Any justification for separate database
ThreadText: # Any justification for separate database
  
  (Asked by: username_0 on 2016-02-03)
  
  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.
  
  -- username_0
  
  **Tags:** best-practice, backups, sysadmin
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_1 on 2016-02-03. Score: 9
  
  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](https://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation)
  
  
  ---
  
  ### Answer by username_2 on 2016-02-03. Score: 4
  
  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 by username_3 on 2016-02-13. Score: 3
  
  I use separate database whenever possible, for a few reasons, many of which username_1 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 by username_4 on 2016-05-18. Score: 1
  
  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.
  
  
  ---
  
  