A dashboard that used to load instantly now takes three seconds. Someone suggests upgrading the server. It's an easy yes, and it usually doesn't fix anything.
Most of the time, the database isn't underpowered, it just doesn't have an efficient way to find what you're asking for. Think of it like a warehouse: labelled boxes and you walk straight to what you need, unlabelled boxes and someone opens every one until they find it. As data grows, an unlabelled warehouse gets punishingly slow no matter how big you make the building. In database terms, that labelling system is an index. I'd rather spend twenty minutes checking whether the right one exists than approve a server upgrade that may not move the needle at all.
It's worth knowing that adding an index isn't automatically the fix either. A table can have five indexes and still answer a common query slowly, because the index has to match the exact combination and order of things being searched for. An index built for "search by status" doesn't help a query that searches by company and status and date together, even though status is technically covered. I've seen this trip up teams more than once: they see an unindexed column, add an index, and the query barely moves, because the real fix was an index built around how the application actually asks the question, not any single column in isolation.
There's also a point worth flagging in the other direction: indexes aren't free. Every one has to be updated whenever the underlying data changes, so a table with ten rarely used indexes can make every single write slower, not just reads. I don't think "can we add an index" is the right question at all. What I'd actually want to know is which queries matter to the business and what's the cheapest route to answering them.
A second, sneakier version of this problem has nothing to do with indexes. It shows up when an app quietly makes many small requests instead of one efficient one. A page loading ten customers might make thirty or forty separate database trips behind the scenes to pull related data for each. Invisible with five test users. At 60,000 real customers, the same screen starts to drag, and nobody can point to one cause because no individual step looks slow.
Both of these share a signature: nothing looks technically broken, everything just feels heavier than it should, and the instinctive fix treats the symptom instead of the cause. I've found the actual fix is usually cheap once diagnosed and expensive to leave alone. A well-run engineering team can typically find the real cause of a slow screen in under a day. Most databases will literally show you the exact route they plan to take for any given query if you ask, which is the fastest way I know to tell a genuine capacity problem from a "we never told it how we search" problem.
Ask your team: When was the last time we looked at why a specific slow screen or process is actually slow, before we talked about upgrading anything or adding more servers?
If nobody has a recent answer, that's worth twenty minutes on your next engineering check in. It's a much cheaper conversation than the one about server costs.