Database abstraction isn't, or at least isn't practical.

Small projects don't need an interchangeable database. Bigger projects won't let you get away without making assumptions about the database. Nothing but the basics work the same between SQLite and ORACLE.

SQLite... Oracle? never used either one, but I believe it.

I'm talking about MySQL vs. Postgres.

Depends on your abstraction system. If we're talking about SQL, the incompatibilities abound. And ORM's or other libraries tend to be either very, very complex or tend to implement everything in the most simple way. Both not very good for performance. Never mind that most frameworks don't have the same level of support for every DB (open source libraries tend to have very limited Oracle/SQL Server support)

And this is only talking about queries, once we get to triggers, constraints or even stored procedures…

I'm thinking on a fairly medium scale, I guess, and mainly just about PG/MySQL. (You mean other databases exist?? Never even seen such a thing!).

It's very helpful to know what's going on behind the scenes of that pretty little database abstraction, though.

If I ever have to care, hopefully I'll be hiring some guy with a beard to think about that for me.