That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components, etc) then moving to a different database is a relatively simple matter of updating your DB layer. A database abstraction makes people think "I can change my database just by changing the db adapter, so why think about my DB code at all!" That is the problem.

You don't need a wrapper that understands the APIs for different databases when you're only using one database. What you need is to think about how you write your code.