Skip to main content

ORMs: My Journey from ADO.NET to SQLC

(The Timeline of a Backend Dev Who Grew Up in SQL)

2015–2016: College / OLTP​

  • Learning SQL the old-school way
  • Access DBs, connection drivers, working inside IDEs
  • SQL felt natural — it's basically English
  • Had no clue what an “ORM” was (didn’t need one)

2017–2018: SQL Saturdays & BI Dev​

  • Living in SSMS, Tableau, PowerBI — OLAP mindset
  • Started building local tools → needed persistent storage
  • ADO.NET was the first time I touched SQL from OOP/imperative code
  • Still no ORM — still no problem

2018–2019: First Portfolio Site​

  • Enter EF / EF Core
  • “Okay cool… I don’t have to hand-write ‘DROP ALL TABLES’ anymore”
  • But... all this indirection? This isn’t faster, just different
  • 🧠 My perspective:

    ORMs solve a problem that doesn’t really exist — at the cost of mental overhead

2020: Tried Django​

  • Did a full tutorial — actually liked it
  • But moved on quickly to…

2020–2022: Frontend First Era​

  • Node server serving JSON from files
  • Design-first mindset: "Just return the shape I want"
  • No DB, no ORM, no problem

2024: Django at Work​

  • Real job, real project, real ORM
  • Slowly grew to appreciate the tooling
  • Especially when used with intention and constraints

2024: SQLC Changes Everything​

  • Found SQLC → instant dopamine hit
  • “YES. This is what should be generated. Not your models. Not your views. Just the DB layer.”
  • Write SQL → get safe, typed Go methods
  • Let me own my DDL/DML. Let my code reflect it.

2025: Go vs Django — Developer UX Tradeoffs​

  • Raw Go + SQLC = fast, explicit, but fewer affordances
  • Django = fast scaffolding, but encourages magic
  • Django migrations? Easy
  • Go migrations? Shell script with psql to nuke and reinit 😂, which is ironically exactly what I did in 2018-2019 ADO.NET days... but I wasn't a termit back then

Where I Stand Now​

Django is often touted as the best tool for MVPs — and yeah, it probably is faster to get something working. But there are tradeoffs. That speed comes from scaffolding and generic patterns, but that can encourage you to expose full CRUD for every model, build uninspired UIs, and defer meaningful design decisions until later.

That’s fine if your data model is already clear and you just need to give users a way to interact with it — even if the end result has your users feeling more like it's a data input job than an intuitive enjoyable valuable user experience. (b/c this is temporary... obviously not long term)

I’m feeling this tradeoff firsthand in two of my current projects:

  • In one, the user flow is crystal clear — just a few models and userflows that result in well-defined sequences of requests. For that, Go + SQLC is perfect. I get to keep the queries tightly bound to the actual business logic and UI, which makes it easier to avoid the trap of generic interfaces and "just make everything editable" design.

  • In the other, I haven’t been hit with that inspiration yet, and there are tons of models So I’m defaulting to Django + CRUD forms — not because it’s ideal, but because it lets me move while the user flow is still fuzzy.

It’s not about which stack is better — it’s about what level of clarity you have at the start. I even built out project templates for both so I can start fast, whether I’m in “just ship it” mode or “let me shape this precisely” mode.