Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This may be a no-brainer to some of you, but I am a newcomer to DBA and this question popped into my head and I couldn't answer it on my own and so I am turning to the experts here.

I have a app that requires two databases –– one production and one for staging. Do I need 2 database servers, or should I use one server and simply keep them in different databases?

On the one hand, you can create a new server using Docker containers so easily. I've been wondering if keeping the data for two environments on the same database is a safe approach.

share|improve this question

You need at least two. Don't mess around in production.

share|improve this answer
Seconded - mess around all you like in Dev, Test, UAT and Staging - keep Prod clear from everything and anything that could slow_it/bring_it down. – Vérace Jul 5 '14 at 23:05
Absolutely, never do anything in production besides production. Staging, QA, UAT, Dec, etc. can all be VMs, even if production is a physical server. – mrdenny Jul 6 '14 at 4:26

You need at least three servers in your scenario - Production, DR and Staging/UAT, all physically separate and sharing no infrastructure. Not even for basic services like DNS, LDAP, etc. Trust me on this.

A good strategy is to replicate Prod to DR, then backup DR to tape (offloading the work of the backup from Prod) then use that tape backup to refresh Staging, which gives you confidence that your tapes work and that your operators are very familiar with the restore process should it ever be needed. Every 6 months, swap Prod and DR around.

share|improve this answer
Please define DR for us. And not everyone needs a separate DR server, though I would also recommend it as a simple strategy, especially with streaming replication working out of the box. – Colin 't Hart Jul 6 '14 at 11:08
Disaster recovery also known as business continuity is having the ability to continue to operate even after the catastrophic failure of your main systems. Is that what you mean? IMHO if you have something that you call "production" then needing DR is a given. Or it's not "production" at all, just a toy. – Gaius Jul 6 '14 at 13:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.