>Another almost worst thing is having production environments with significantly different stacks to what you are using locally,

Everyone has a test environment, some people also have a seperate production environment :D

Database/datasize issues typically are the worst here. Dev/UAT environments are typically considered a cost center and you'll commonly see them with some small amount of ram and compute resources. Which is fine when you're testing 'small data'. But if you have enterprise style clients that have hundreds of gigs/terabytes of data, your dev environment behavior is generally going to be very different.

Ran into a case where an enterprise client ran massive db performance problems. We found an unindexed table scan that was killing performance. When doing a post mortem on it, it turns out that 95% of our customers only had around 5 entries in the table. No reason to add an index to that. But this customer had found a neat and interesting workflow that had added thousands of entries to that table.

>This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally.

Did you consider running a second test instance of the DB in the cloud?

> Did you consider running a second test instance of the DB in the cloud?

This is using the test instance :) The issue replicates both on prod (cloud) and test (cloud).

But not locally. So a nice 30 minute deployment pipeline run to test if your fix worked, since we are firewalled from direct DB connections from local dev machines, even for test instances.

I've got a 10 min lag. Now i don't feel so bad.

SOP though..