You don't need an ORM for migrations. Tools like flyway and others can rely purely on `.sql` files with some naming conventions and can help keep your app and d

You don't need an ORM for migrations. Tools like flyway and others can rely purely on `.sql` files with some naming conventions and can help keep your app and db schemas in sync. You also don't need an ORM for security, and an ORM doesn't always prevent you from footgunning. Use query builders, `?` or `:named` placeholders (as your DB driver recommends), and almost never use string operations to build queries. Similarly, grow suspicious of your db or application model if you find yourself having to write increasing amounts of SQL to appease your ORM. ORMs are a tool. Neither good or bad on their own. Many applications outgrow them, or they don't properly refine their object models as the db or application changes. Lots of applications hold on to the security blanket of their ORMs for far too long, or they let the DB objects proliferate very deeply into their stack such that changing the db or the app model become nearly impossible. This is when apps increasingly try to outsmart the ORM, creating massive amounts of tension and friction in doing even simple things. (As anyone who has tried to do large-scale migrations or backfills that weren't possible in raw sql will tell you.) Learning to recognize all this is above the level of "amateur", but it seems like you've already learned to identify some of the good that the tooling can provide.