[banish-m4]

Ex-Rails here.

Rails can optionally use SQL migrations, UUIDs for pks, enforce referential integrity with additional options, and create additional indexes easily. The value of ORMs comes in separating domain data modeling from the peculiarities of a DBMS'es SQL flavor.

An ORM should be used to automate the commonplace rather than as a substitute for understanding how to manage and operate a DBMS.

SQL knowledge is often needed for cleanup and ETL work outside of the monolith. There is no substitute for understanding how things deeper in the stack operate.

[jon-wood]

I’m increasingly cold on ORMs existing to abstract away the specifics of your DBMS. In my entire career I think I’ve seen one migration between different databases (MySQL to Postgres), and it was an undertaking despite using an ORM.

Where I do appreciate ORMs is in being able to bridge between the relational world of SQL and the object oriented or functional world of the application. Occasionally I’ll decide an application is stupidly simple and it’s not worth the overhead of an ORM, I’ll just write SQL directly. I regret it every single time, because inevitably I end up implementing a half-baked ORM to make the results usable in the application layer.

And yes, as you say, regardless of an ORM you need to understand the database underneath and the SQL being generated. I’ve seen so many developers who are completely baffled by why their code is running slowly when a quick EXPLAIN will surface the fact they’re doing a sequential scan over several million rows of data.

[jorl17]

> I’m increasingly cold on ORMs existing to abstract away the specifics of your DBMS. In my entire career I think I’ve seen one migration between different databases (MySQL to Postgres), and it was an undertaking despite using an ORM.

I've always viewed it more as "we can start fresh with another database with ease" and not "we can migrate from a database to another quickly".

And when I say "start fresh", I don't literally mean starting fresh. It can just mean I write my packages (e.g. Django's "Applications") in a database-independent way and whoever ends up using it can use it with whatever DB they have.

Perhaps your vision is indeed what is often sold, though I never saw it that way.