I’m working on a backend service and trying to decide between writing direct SQL statements or using an ORM framework like GORM or upper/db. When I tried switching to upper/db, I had to rewrite most of my database code and ran into new issues that weren’t there before. This made me wonder what approach real companies actually use in their live systems. Is it better to stick with simple SQL queries or should I invest time in learning an ORM? My current project is small but might grow larger in the future. What would be the better choice for scalability and maintenance?
I’ve tried both approaches across several production setups, and honestly? Start with plain SQL for what you’re doing now. That rewrite pain you hit with upper/db is exactly why so many teams skip ORMs on smaller projects - the learning curve and migration headaches just aren’t worth it early on. Raw SQL gives you total control and you can see exactly what’s happening, which is huge when you’re debugging performance issues in prod. But here’s the thing - once your app gets complex enough, you’ll start repeating the same query patterns over and over, and that’s when mistakes creep in. That’s your cue to bring in an ORM, but do it piece by piece instead of another big rewrite. Tons of successful companies go hybrid - ORM for basic CRUD stuff, raw SQL for the complex or performance-critical queries.
From maintaining legacy systems, it really depends on your team’s SQL skills and how much database logic you’ve got. I’ve seen devs use ORMs as a crutch to avoid learning proper SQL - backfired hard when they needed to optimize queries or handle complex joins. The generated SQL was garbage and debugging performance issues became a nightmare. But I’ve also worked on codebases with hundreds of handwritten SQL queries everywhere. Making schema changes was like walking through a minefield. The sweet spot I’ve found? Plain SQL for anything non-trivial, query builders for simple stuff. You get the performance benefits where it matters most, but still have protection against SQL injection and basic maintenance headaches. Don’t go full ORM just because it’s trendy.
Just go with whatever gets you shipping faster right now. I’ve seen startups get acquired running on raw SQL and Fortune 500 companies with huge ORM codebases. The “right” choice is what your team can maintain without breaking production every other week.