Anyway, it doesn't get much simpler than: add_index :users, :account_id
Near trivial example: what index or indices do you need to support the business requirement "I want to know how long users stay active after they sign up, and I want you to be able to slice that data by signup date and by whether they're paying customers or not."
So programmer Bob goes off and does this.
"Oh, Bob, the screen only lets me slice the data by signup date and by customer type, but I want to slice by both at once."
So Bob makes a one line tweak to his controller (to use both conditions, instead of one or the other)... and BOOM, down goes the poor server.
But yeah. It's complicated. "Software is hard." But the best thing you can do is become aware of your ignorance, then try to eliminate what you can.
We do this at the day job. It runs about $X00 an hour, with a minimum of Y hours, if our customers need it. Heroku, on the other hand, has a lot of customers who are wondering how far their $50 a month is going to get them. For these customers, many of whom are Rails types who don't quite grok indexes, it might be a better solution to say "Um, look, rather than us teaching you a core engineering skill that you're manifestly unwilling to pay for, how about we suggest a technology stack that makes this skill unnecessary".
Previously, one of the Rails hosts (Dreamhost or Heroku, can't remember) released stats saying something like 97% of customers create no indexes. I totally understand how that can happen, too -- you expect ActiveRecord to be magic, and with what it does it is very powerful magic, but it is not magic that totally obviates your need to think about database design. (Edited to add: My business runs on Rails, I consider myself to have low to intermediate SQL ability, and if you contact my day job to get consulting on your database woes you won't get handed off to me anytime soon.)