SQL is good actually. Using your database system to define your data model along with all of its constraints is much better than just scribbling out some Rust/TypeScript/Go datatypes and shitting them out into a schema with a new database migration every fucking commit.
Your SQL application does not need to be portable. You don't need an over-engineered rube-goldberg solution where you can slot out OracleDB for SQLite for fucking CSV documents. Your code SHOULD be ANSI/ISO standard, but it just needs to run on PostgreSQL. PostgeSQL is portable.
Thanks for coming to my TED talk.
Who says it's not?
This is what you're doing with or without an ORM. It's just a question of which language you're doing it it.
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.
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.