2 ms·
Why would you configure your column database as multiregion in every environment? You can run 99% of your tests, iteration, validation, etc, against a single sh
by andrewstuart2 4y ago
Why would you configure your column database as multiregion in every environment? You can run 99% of your tests, iteration, validation, etc, against a single shard. And even the same instance if you don't need to make any schema changes. You don't need a faithful production performance match until you want to validate performance characteristics, which often comes long after you've validated other correctness criteria that doesn't need prod-scale infra.
So once you've validated everything, you maybe stand up the prod-scale stack for less than an hour to run your at-scale tests, then tear it down again. Definitely not doubling your cost because you're not keeping anything around, and you're only using it when needed. Most places in my experience actually don't do this, and instead have a copy stood up somewhere just wasting money as you've described.
- ffggffggj 4y agoOne reason is that transaction performance could be very different, even regardless to data volume. Your points are all correct of course, but then that wouldn’t be a preview environment, would it? It would be shared database state in a database staging environment. Which, for what it’s worth, is also how I have seen this problem managed when it came up. As for costs, maybe true, but it could also take a lot longer than an hour to bring up a large deployment. And if every engineer is doing this for one hour a week, and you have a few dozen engineers, there’s a 2x cost increase with a tougher capacity planning problem since your load is now tied to your hiring plans.