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.

Exactly. It seemed to me as if the author originally thought with a framework they don't ever have to think about the architecture, but of course it's still possible to shoot yourself in the foot and end up with a tangled unrefactorable mess. The article channels misplaced disappointment.

Give it some thought and properly encapsulate your core business logic and you won't have that much trouble migrating to another framework or a custom solution if need be (especially easy if your current framework has good documentation, which Django definitely does).

Large firms have the resources to overhaul infrastructure, and even with a project failure rate of 54% often manage to complete migrations.

Only small shops get hit hard when things go wrong.