Test data only has a "realistic shape" in some applications; applications with short small transactions and low cardinality relationships. I agree keeping the d

Test data only has a "realistic shape" in some applications; applications with short small transactions and low cardinality relationships. I agree keeping the data isn't a bad idea in those cases. It's probably normal in B2C apps. Some B2B apps have large background transactions with 100k to 10s of millions of rows inserted or updated (with application controlled queuing rather than only relying on database locking), and you won't get realistically shaped data long term on unit tests designed to run in reasonable time. It's just as easy to end up with a performance problem in test code that you never see in production. Except when you have a customer who tests your service remotely on an automated basis. That can be annoying.