Counterpoint: nah fuck that

ORM bros be like “I just jammed a giant chunk of data across the network so I could turn it into a dataframe and then filter it down, and oh by the way I think our server needs more RAM and processing power”

sqlite is all you need, big sql will try to convince you otherwise

use a good ORM, like Efcore

Having strict typing and references for accessing your db is essential for refactoring jobs. Having to fucking query where a property is used in stored procedures is pure hell. Deploying new versions of your code with migrations is also so much easier than orchestrating sql execution alongside code execution.

Being able to write

dbcontext.Users.Where(x => x.IsAdmin).Select(x => x.UserName).ToListAsync() and execute exactly the sql you would write is awesome, and not have to fuck around with sql is great.

people will build horrible nightmares out of whatever tools you give them, unless they have a fair amount of experience/knowledge and put real effort into planning their data model and queries, which is always going to be a small minority of developers.

But personally I tend to have the same preference, I’d rather keep it simple and directly use the db tools as intended.

Being able to use set theory and do the symmetric difference of two QuerySets without bogging down in the SQL subquery syntax and instead have the ORM do it is far more powerful.

If you don’t think an ORM is good, you probably haven’t written a complex enough SQL query by hand to realize what an ORM gives you

One of the dumbest things ORM defenders bring up is:

but what if I need to change my database mid-project?

Lmao no you fucking don’t. Also that’s stupid. Shut up.

There is nothing better than plain SQL.

SQL is the most idiotic programming language i’ve ever seen. Select blabla from x, IDE can’t help you with select as it does not yet know FROM where. Try making a list inside the query, that needs weird hackery because the programming language whose only job is operating on lists can’t even define lists in code.

If I had to write database code I would use something like JDBI or jOOQ (Java libraries for interacting with SQL databases) instead of directly writing most of the SQL. ORMs do sound like a poor abstraction.

I use drizzle and like it, actually. You still are constructing SQL queries, you still have to understand SQL, but you get some nice type safety from TS and more powerful auto complete than other query tools.

Also, how does writing SQL queries by hand lead to less frequent migrations?

The great thing about tech work is that I worked in tech doing software engineering in the pre-personal-disaster times and I still have almost no idea what any of what you’re saying means.

TBF I didn’t understand 30% of what my coworkers were saying anyway. Sure, we can totally use poetry and lint to make installing packages and standardizing our style easier, that’s definitely more comprehensive than just using the tried and true requirements.txt and pyenv and having a list of stylistic conventions to consult when writing code. Oh, you want to try adding Glorple to Docker because Github Copilot said it’ll help? Go off, who am I to object. I blink and look away for five seconds and instead of using Vue we’re going to use Onigiri because it’s got a slightly different approach to JS or TS, I still don’t know which one we’re actually using because nobody can explain to me what the difference between a language and a framework is. The guy who got us using poetry has been fired despite being more competent than the rest of us, but we’re still stuck with this tool I can’t force myself to learn because the old way worked fine and was comprehensible, human readable, while this poetry stuff is 1. harder to comprehend, and 2. NOT POETIC THEREFORE IT IS NOT POETRY. POETRY IS WHEN WILFRED OWEN LAMENTED ABOUT WAR CRIMES IN WW1, NOT WHATEVER THIS ABOMINATION IS.

Meanwhile someone else has innovated where innovation was not needed and he’s telling me we need to incorporate Cheesecake, which I can get at Fort Something. I ask if there’s any licensing requirements. He acts like I’m being a stickler for asking these questions, which I was trained to ask at a previous job because there can be severe financial consequences for companies caught using software without the right license. “It’s open source, cuddle”. “Yes but I’ve seen stuff that was free for individuals but companies needed an enterprise license and at my last job we’d ask the legal nerds to get us licenses, is this one of those cases? Kind of looks like it to me.” “Dammit. Alright fine, we won’t use Cheesecake, we’ll use Camembert-Flatbread instead, it’s similar but doesn’t have that licensing language.” Me: Still at that Fort? I can’t find the Fort on Google Maps. Coworker: No it’s a website. Me: But why’s it called a fort? Is there some military thing going on here, because I won’t touch anything military. Him: No they just thought the name sounded cool.

So then, feeling like I’m being trolled by my manchild of a supervisor, I google search for Camembert-Flatbread at Fort Something only to discover it’s real, and then I have to deal with the indignity of using such a ridiculously named tool.

(I made up some of these words but it doesn’t matter because if I didn’t know I’d made them up I legitimately wouldn’t be able to tell it was made up)

(2 bloody years at that job and if someone asked me to explain what I did I wouldn’t even be able to explain beyond “I wrote code to make things do things in an application that did other things. Language? Python, and some other shit I don’t know what it’s called.”)

SQL is good actually.

Who says it’s not?

Using your database system to define your data model along with all of its constraints…

This is what you’re doing with or without an ORM. It’s just a question of which language you’re doing it it.

…with a new database migration every fucking commit.

Again, this is what you’re doing with or without an ORM. When you have business-layer changes that require data schema changes, orchestrating those schema changes in a way that preserves data is a thing you have to do. If you’re not using an ORM and associated tooling, you’re doing it by hand.

You don’t need an over-engineered rube-goldberg solution where you can slot out OracleDB for SQLite for fucking CSV documents.

ORMs are NOT intended to make the database layer something you can swap out on a whim. That’s a pretty common belief, but it’s a fallacy.