If you don't have any discipline it becomes hell.
Not to mention that a random team writing a migration that locks a key shared table (or otherwise chokes resources) now causes outages for everyone.
Not to mention that a random team writing a migration that locks a key shared table (or otherwise chokes resources) now causes outages for everyone.
- Docs and guidelines on migrations would have been written
- Some level of approval and review is required before execution
These are things that isn't really postgres specific, any company that doesn't have those is going to be a nightmare.
e.g. User management deploy has somehow taken down core payment processing.
Overengineering is a plague amongst SWEs, and almost as dangerous as failing to sell the product in the market.
Sorry if this comes off as brusque, but I've seen good engineers want to use Elasticache for the right reasons and seen "leaders" tell them no because "caching is one of the hard problems in computer science."
Leadership-by-folksy-saying is sadly a real thing.
Not dealing with loads of technology choices in the early days is a boon.
Once we hit more than $100m in rev it made sense to allow a bit more optimisation for purpose - but only when we had cash flow to pay for it. Otherwise all these fancy-shmancy choices are just dressed-up tech debt.
Yeah my original comment was about experiences working at places with this kind of monetary success (if not more) and stubbornly not evolving. Low trust eng leadership philosophies will do that though.