[monadic2]

Typically, something like this: you do something stupid like use an alternative primary key scheme (which the database is agnostic about) and then your teammate accidentally omits a parameter of the primary key, deploys to production, the query misses all the indexes and causes an incident with downtime. You don't see this problem quite as much when you're staring at the schema itself and writing code against it.

More problems: default scopes causing large refactor pain, modular queries leading to accidental joins and index misses, models containing all of the combinations of models-to-be-rows, models-that-may-be-up-to-date, and models-that-have-already-been-deleted. I prefer explicit lifecycles to avoid semantic ambiguity when it comes to what data to expect where and wehen. Generally, all the places you would expect treating database queries as code against domain objects with different semantics than database tables.

Or, my personal least favorite game, "spend three hours translating this performant query into horrendous, unreadable ruby that technically produces the sql you wanted all along". I've found this comes up repeatedly with aggregate queries and joins and window functions.

Hey ORMs have their place, but I don't get the point of pretending it's even equivalent to SQL when they were built with completely different intentions and constraints.