One thing I've enjoyed so far about being a contractor (but not a consultant) is that even as a relatively junior developer, I get to see the dirty internals of many different companies, and spot patterns between them. This is one of them.
I've been at companies that decided to switch to hot new NoSQL distributed fault-tolerant join-free key-value vector clock databases, when really they only needed to add a couple of indexes to a few heavily-queried fields. I've seen language switches and full re-architectures based on perceived performance problems, but the complexities of the new architecture made request latencies worse (c.f. https://en.wikipedia.org/wiki/Second-system_effect).
The best approach I've seen so far is described as 'list, rank, iterate'. Profile your problems aggressively, rank the issues in descending order of importance, and greedily work your way down the list, fixing them.
Before NoSQL was a thing, I saw people break their data out into 1000s of .txt files to get around this.