The bug lived only in production, and only for users who had more than one open obligation at the same time.
I was matching an incoming payment to the obligation it belonged to. The query pulled candidate matches by requisites, and the code took the first row as the one to apply. On my machine that was the right row every time: the oldest open obligation. Small table, sequential scan, so rows came back in insertion order. It looked deterministic because locally it was.
In production that same table had enough rows, and the right index, that the planner stopped reading it in insertion order. The query had no ORDER BY. So "first row" quietly became "whatever the plan returned first", and some payments landed on the wrong obligation. Not often. Never with an error. Just a balance that was off, surfaced during reconciliation days later, by which point the cheap fix had already become a correction with a paper trail.
The fix was one line. The lesson was not.
Now any query whose result feeds a decision carries an explicit total order, down to a tiebreaker on the primary key. And I read "take the first row" as a code smell unless the ordering is written next to it. My local database being small was the entire illusion.
Where have you seen implicit ordering turn into a correctness bug instead of a cosmetic one?