So let's say you're writing software for some company. Best practices, as I understand them, would dictate that for dev purposes, you populate your DB with fake data. There are a number of benefits to this.
If you're going to be using, say, Vagrant to manage your dev environment, most of the pre-built images have HDD's of a limited size. Like let's say production has 100's of GB of data. Your Vagrant box isn't likely going to be that big. Also, if you're doing continuous integration testing, you're probably not gonna want to do it with a production size DB.
In theory, developers ought not have personally identifiable info of real world customers and this facilitates that.
One big problem I see with this, however, is... let's say your dev DB is, all together, maybe 1MB in size, whilst production is 100's of GB in size. A developer might write a query that JOINs tables together on unindexed columns. Maybe with 1MB of data it works great but with 100's of GB of data?
How is one supposed to deal with this problem?
(for that matter, there can sometimes be an excessive amount of red tape to cut through to get production data to accurately reproduce an issue specific to a customer, but that's an organizational problem - not a technical one)
How is one supposed to deal with this problem?
-- By following sensible indexing and querying practices, optionally verified by executing performance tests on large data sets. Note that you can still get a pretty good performance indicator when testing with smaller databases.