3 ms·
Couldn’t agree more. Having full sized and fully speced dev and test DBs is wasteful and not realistic across several independent teams. Monitoring prod closel
by holografix 4y ago
Couldn’t agree more. Having full sized and fully speced dev and test DBs is wasteful and not realistic across several independent teams.
Monitoring prod closely and understanding what could constitute a costly workload/query which would in turn require a temporary test env with similar sized dataset is the correct approach.
- samokhvalov 4y agoThis is too reactive approach, isn't it? Imagine a system that could do this in CI/CD pipelines: 1) first, run all the tests on a tiny DB as usual 2) extract queries 3) run them against full-size DB branch/thin clone (thin provisioning, CoW; PII is not there of course, wiped out for security/compliance) -- auto-guessing parms, that's the trickiest part, but assume it's solved 4) collect all the details about performance, focusing on IO numbers (rows, block read/writes) 5) if some queries are off – say, you forgot LIMIT – post a warning, block the change, do not allow deploying it, letting backend dev fix it. This would be proactive. And it's becoming possible with modern tools.