I remember those jolly days when you could just clone production DB and restore it into your local machine.<p>These days I can&#x27;t even do it to a single of our avg size tables.<p>Anyway, counting on production data for testing is a mistake.<p>We do a couple of things<p>1. Testing
For testing we use fixtures with a build and tear process. Basically building the test with data and in tear down clearing the database.<p>Language and framework is irrelevant here, every single one that I know of has this features built in.<p>2. Staging&#x2F;Princess
For staging, we clone production periodically but we have a &quot;whitening&quot; process.
a. Remove all emails, remove all keys&#x2F;tokens.
b. Delete tables for stats that only relate to production (orders etc...)
c. Delete all push tokens, no one from staging will ever get tweeted&#x2F;push notification or anything like that.<p>I would NEVER point staging&#x2F;test to production, not even for read only. Staging&#x2F;Test should be on a security group that doesn&#x27;t even have access to production DB.