I've always heard that it is bad practice to develop against production data and am currently in the process of moving to a Dev>Stage>Production model, mainly because I have a new employee with minimal skills and I'd rather not have him work directly with production data yet.

But for a long time I've worked directly with production data with minimal headaches, except for maybe a few errors creeping in here or there, things like spelling issues, bad alt text, links pointing to the wrong location. This seems to be due to a lack of peer review on my part, not because of working with live data.

So why is developing on the live site such bad practice?

  • You could just duplicate the data you have on your production server on the development server.
    – HoLyVieR
    Jul 14, 2010 at 15:36
  • 1
    mmmm... how do I upvote this question without appearing as supporting your way to do things directly with production data? :S
    – vmarquez
    Jul 14, 2010 at 16:50
  • 2
    @vmarquez Is a question about a bad practice necessarily a bad question?
    – user42
    Jul 14, 2010 at 17:14
  • No. It is not. I was about to vote-up because I had the feeling that this kind of questions are a great form to educate on best practices, and then, somehow, I got the idea on my mind that voting-up could be taken as a tacit approval on the bad practice, thus, provoking exactly the opposite effect. Now I think voting can be misleading... at least on some cases.
    – vmarquez
    Jul 14, 2010 at 18:04
  • 1
    People vote on things for all kinds of different reasons. I don't take a vote as anything other than "this person got something out of this question."
    – artlung
    Jul 14, 2010 at 20:56

5 Answers 5


If during development you are running SQL commands that include INSERT or UPDATE on existing database tables, you are running a risk to the extent that those database tables are mission critical.

Some places sync production data into the development database at some interval, say, once a week or at developer request so you have fresh data to develop with.

But if your production data is not at risk from what you're doing, for example, if you were simply developing a view of some data, usually it's not a big deal. Now, if you're running reports that do table scans, then you have the potential to lock up a table, then your existing users get affected.

I'd defer to my Database Administrator in cases like this, if there's no "official" DBA, I'd err on the side of caution. It's simple enough to create a development database, even for myself. On a team it's vital. Failing that, if you were insistent about hving only one database, you could prefix your development database tables with DEV_ and feel a bit better. Yes, that requires some code changes, but in development adding some variables during development $debug = true, etc, is usually worth the effort.

Lots of ways to approach this. It's very dependent on your situation.

  • +1 on the sync process. We do that on demand here for our development. We also have a QA which is a more often synced area for final review of changes before they hit production. But we do run queries against production data sometimes, just because the issue is data related and very hard to replicate.
    – Milner
    Jul 14, 2010 at 20:23
  • +1 and sync can be tricky. In many cases, you'll want to do things as part of the Prod->Test push like scrub email addresses and names, etc to avoid accidentally emailing "Dear Rich Bastard"
    – JasonBirch
    Jul 15, 2010 at 5:27

You do NOT want to develop against production data on your production server. There are a couple of huge reason.

  1. Development slows down your production box and creates vulnerabilities. What happens if you leave your computer unlocked and walk away?
  2. If you make a mistake people that visit your site can see it.
  3. If you do any kind of data update inside of a Transaction in your database and you don't commit it immediately or the transaction takes a while to finish you will put a lock on all of the tables involved and you could cause a timeout to occur.
  4. Some database systems, specifically SQL Server will do table locks at times on SELECT statements alone! Which means you can unintentionally give people timeouts or error pages on your site.

I would never do development work on a live box if possible. Your best bet is to make a backup of the Database and pages and work with the copy and then push your updates. One tool that has helped me a ton is Msft's SyncToy.


Well, you can really mess it up the data. Imagine leaving off a where clause. Even if you have hourly backups, that would be a pain to fix.


If you don't drive without a seatbelt, don't develop on production data. Just a safety issue.


If you have production data available, it is reasonable to use them for testing, but use a separate testing database with a copy of that data. Otherwise many things will work for your few "blabla" testing records but not for a real scenario.

And for developing on a live production data - remember the Murphy's laws "Anything that can go wrong will go wrong.", and it is so easy to make a small mistake with large bad consequences .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy