How do you explain a database decision, like adding an index or denormalising a table, to developers or managers who are not database specialists?

Translate the decision into the currency your listener cares about — time, money, or risk — and keep the internals out of it unless you are asked.

• For developers, frame it as behaviour they will see: "this index means the search endpoint stops scanning 4 million rows, so the page loads in 40ms instead of 3 seconds — but every INSERT into this table now costs a little more."
• For managers, frame it as cost and risk: "this change lets us stay on the current instance size for another year" or "without it, checkout starts timing out during a sale."

Always state the trade-off out loud. Indexes speed up reads and slow down writes; denormalising speeds up reads and creates a consistency problem you now have to own. Presenting only the upside is what makes non-specialists distrust database advice.

Note: If you have ever written a short design document or run a lunch-and-learn on this, mention it. It signals that you scale your knowledge rather than hoarding it.