So use an ORM so you don't have to write and maintain SQL is bad, because writing and maintaining SQL is not expensive, but using an ORM is (at least in my experience: I've run into many cases where the ORM generates pathological queries that aren't fixable without throwing away all the code that was calling into the ORM; where a bad query in plain SQL is usually readily accessible).
On the other hand, use Erlang's hot code loading so you don't have to restart nodes to update code is not bad: hot code loading isn't super expensive (you have to do a little bit of planning for some types of changes), but restarting nodes is (first you have to move all the traffic, then you have to actually restart it, then you have to move the traffic back).
Not kwowing how to write proper SQL is a problem, and ORM won't solve that for you.
The correct answer is to forget about database independence and double down on just one so you can use it to its full potential.
: And obviously it should be Postgres...
when you are not writing a SaaS, but shipping a piece of software for a customer to run on their own server, it's a very common use case to support different database vendors - especially in enterprise software.
There are non-abstractable differences once you no longer have a toy project, e.g. locking and isolation semantics.
There might be some valid reason for making your applications talk to different DBMS, but you have a tough slog ahead no matter how you do it.
Yeah, sure, go tell that to your manager who promised multi vendor compat to your clients.
Problems with the ORM nowadays always stem from developers who are ignorant of SQL. Those people should not be working for you anyway.
Okay, I'll tell him that 5x the systems means more work, possible bugs, etc. Seems logical.
I'll tell him the same thing if he promises Windows, Mac, Linux, Solaris, and Plan 9 compatibility.
I'm not saying you shouldn't be able to use the same application with several databases; I'm saying you should avoid it.