Answers: <p>Putting them both on the same server is certainly the easiest. However, I'd argue in a business situation you shouldn't be <em>able</em> to do it.</p>
  
  <p>A production database is one of the most important resources of a web app. It likely has much confidential data in it. It's also probably critical to the site's stability. So the production database credentials should be tightly controlled, and firewall rules should prevent access to it except from a small number of vetted machines. In addition to security considerations, the firewall rules also help prevent accidental test operations on the production database - if it can happen, it will sooner or later.</p>
  
  <p>Edit: Shortly after I originally wrote this answer, Digital Ocean (one of the largest hosting providers) <a href="https://www.digitalocean.com/company/blog/update-on-the-april-5th-2017-outage/" rel="noreferrer">had an outage</a> that would've been prevented if they had segmented their network appropriately. Learn their lesson instead of repeating the mistake.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-05T18:41:54.540Z
Answers: 2017-04-10T15:11:34.497Z
Answers: 2017-04-10T15:11:34.497Z
Answers: Xiong Chiamiov
Answers: <p>Go with a separate logical server:</p>
  
  <ul>
  <li>It is going to cost the same because you are charged on the <strong>tier</strong> of the database not the database server.</li>
  <li>By providing separate servers you provide <strong>isolation</strong> between the two databases protecting one from the other. </li>
  <li>Unless​ you use contained users your users will be <strong>shared</strong> between Test and Production, if you happen to use the same user for both databases a change of the password in production would also require the same change in Test.</li>
  </ul>
  
  <p>You might want to use the same server for a database if:</p>
  
  <ul>
  <li>You are creating a very large number of Databases <strong>across many Dev/Test</strong> environments as there is a limit to the total number of SQL Servers. </li>
  <li>You have two databases that need to be deployed as part of the same ARM template.</li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-06T11:30:48.023Z
Answers: I would add a point: having separated servers allow to upgrade Q/A  server and adapt before upgrading production's one.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-04-05T19:02:04.587Z
Answers: 2017-04-05T19:02:04.587Z
Answers: Richard Slater
Body: <p>I'm new to SQL Server, so this may be more of a SQL Server management question. </p>
  
  <p>I'm creating test and production databases for a service, and I imagine I'll be wiping the test database quite a lot. Additionally, I'm going to want different replication and audit logging strategies. </p>
  
  <p>Does it make sense to have both SQL Databases on the same SQL Server, which seems to be what the Azure Portal makes easiest to manage, or does it make more sense to create a separate logical SQL Server for the test and production databases?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-05T18:20:54.060Z
Comments: Hi. Welcome to the site. I did minor edits for better clarity. Pl feel free to revert it back if not appropriate :)
Comments: Dawny33
Tags: <sql><azure>
Title: Separate SQL Server or just separate SQL Database for test and production?
UserDisplayName: Anonymous1
ThreadText: # Separate SQL Server or just separate SQL Database for test and production?
  
  (Asked by: username_0 on 2017-04-05)
  
  I'm new to SQL Server, so this may be more of a SQL Server management question.
  
  I'm creating test and production databases for a service, and I imagine I'll be wiping the test database quite a lot. Additionally, I'm going to want different replication and audit logging strategies.
  
  Does it make sense to have both SQL Databases on the same SQL Server, which seems to be what the Azure Portal makes easiest to manage, or does it make more sense to create a separate logical SQL Server for the test and production databases?
  
  **Tags:** sql, azure
  
  > **Comments:**
  > **username_1**: Hi. Welcome to the site. I did minor edits for better clarity. Pl feel free to revert it back if not appropriate :)  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2017-04-05. Score: 8 | Accepted answer
  
  Go with a separate logical server:
  
  * It is going to cost the same because you are charged on the **tier** of the database not the database server.
  * By providing separate servers you provide **isolation** between the two databases protecting one from the other.
  * Unless​ you use contained users your users will be **shared** between Test and Production, if you happen to use the same user for both databases a change of the password in production would also require the same change in Test.
  
  You might want to use the same server for a database if:
  
  * You are creating a very large number of Databases **across many Dev/Test** environments as there is a limit to the total number of SQL Servers.
  * You have two databases that need to be deployed as part of the same ARM template.
  
  > **Comments:**
  > **username_4**: I would add a point: having separated servers allow to upgrade Q/A  server and adapt before upgrading production's one.  
  
  ---
  
  ### Answer by username_2 on 2017-04-05. Score: 6
  
  Putting them both on the same server is certainly the easiest. However, I'd argue in a business situation you shouldn't be *able* to do it.
  
  A production database is one of the most important resources of a web app. It likely has much confidential data in it. It's also probably critical to the site's stability. So the production database credentials should be tightly controlled, and firewall rules should prevent access to it except from a small number of vetted machines. In addition to security considerations, the firewall rules also help prevent accidental test operations on the production database - if it can happen, it will sooner or later.
  
  Edit: Shortly after I originally wrote this answer, Digital Ocean (one of the largest hosting providers) [had an outage](https://www.digitalocean.com/company/blog/update-on-the-april-5th-2017-outage/) that would've been prevented if they had segmented their network appropriately. Learn their lesson instead of repeating the mistake.
  
  
  ---
  
  