Question

Right now, the devs all have a their local dev environments with a snapshot of the production database – which they can twist, churn and beat up the data without affecting anyone but themselves.

These snapshots are starting to get large, and a data import of them is starting to take close to an hour.

Any better recommendations at maintaining dev data? The dev data can be ripped apart for potential changes, and then need to be put back together if a change idea was bad, etc.

Answer 1

In my experience, having a centralized DB+data for each environment: Development, Testing+Integration and Production has been the best approach.

• Development: let the developers do whatever they want with it. If production-like data is required, obfuscate/remove sensitive data. The more lightweight this database is, the better for you to move, maintain and backup.
• Testing: use it to simulate the production environment and let the
  testers to input/retrieve all the data the want but only through your
  application interfaces. This environment also allows you to test your deployments
  before sending them to production, you don’t want a bad DB installer
  to leave the production app in an unusable state. If required, you
  can input this environment with production data but obfuscate/remove
  sensitive data too. You could use high volumes to spot performance issues before they get to production.
• Production: Leave your production data/environment alone, you don’t
  want sensitive data to end up in the wrong hands or a DB error configuration to allow the developers to change data accidentally.