Ha! This selling point is just one in a miserable litany of poor reasons to use an ORM - you absolutely cannot simply switch between databases without doing some work to ensure that the data is migrated correctly and the SQL statements translate properly.

Yeah, but verification of correctness is much less work than implementation.

As an alternative to an ORM, there is another great abstraction layer that works across a large number of databases. It's called SQL!

Until you realize that not even booleans are standardized between SQL dialects...

That's true in theory, but unfortunately you can still run in to issues when different databases support different parts of SQL, and the db you're migrating from has different features than the one you're migrating to.

There are a huge number of differences in the SQL supported by different engines. You can't just switch from one to another, unless you're only using a small subset of SQL to begin with.

How do you insert a row and get the automatically set Id set by the database portably? That’s a standard create operation.

You still have to migrate the data. I faced the same kind of dilemma, but with MySQL, and kind of noped out when I got to stuff like [0].

[0] https://stackoverflow.com/a/87531/1210797

An ORM does indeed force you to write lowest common denominator code but I wouldn't rely on that.