I don't like ORMs much, admittedly mostly because I did a fair amount of development with SQL before they existed.

But, there was one that I played with that did have appeal to me, RedBeanPHP.

Forgetting that it's PHP for a minute...that's not the main point. It was cool because it had a fluid way of working. It automatically generates the database, tables and columns... on-the-fly, and infers table relations based on naming conventions and how you interact with code. No config files at all.

So, you would iterate in dev solely by writing code, and end up with a schema including foreign relationships. Then, you can "freeze" the schema for prod, turning off all the dynamic stuff.

Their quick tour explains it well: https://redbeanphp.com/index.php?p=/quick_tour

Note: I'm sure it has notable downsides over time, but the approach was really nice starting from scratch.

ORMs where you don't write sql make me nervous, though it doesn't help the main version of this I used was raw linq-to-sql (not Entity Framework), and it could be very hard to convince linq to generate the correct sql for what I was doing (I once had to write my relationships backwards else it kept generating sub queries).

But .NET also has Dapper where it lets you write all the SQL and then it just handles the binding of data into objects, which having that handled for me is great.

I mention because I had something of the opposite experience with it. It not only ended up yielding the correct queries, but I saw a significant increase in performance. And the neat thing about it, beyond ORM and linq-to-sql, is a common interface amongst providers - so you can do things like swap from SQLite to Postgres with 1 line* of code, so long as you're not using provider specific extensions.