Postponing the choice until you have enough data to make an informed decision is a good idea, though, and trying to isolate direct interaction with the database to a relatively small number of code paths would be worth doing regardless. If your code is so entangled with the database code that you can't separate them easily, you have much more immediate problems than theoretically having to coping with scalability someday (if you're lucky).
Out of curiosity, how many times in your career have you decided to switch databases halfway into a project?
In 15 years of doing this for a living, I've never actually needed to do so. With that in mind, I don't feel particularly worried that my SQL is not instantly portable.
I've moved from sqlite to serialization via Lua on one, when clarifying the problem made it clear that using a relational database was actually a poor fit. Most of my examples aren't database-related, though. I agree that switching databases doesn't happen much, I'm just noting that having a major, conceptually distinct part of a project entangled with the others is usually a sign of other problems. (Maybe that's just my experience maintaining legacy codebases, though.)
I think that getting preoccupied with moving from one database to another for scalability reasons is usually wishful thinking -- it's like worrying about all the positive attention you're getting.
in theory lots of things can 'cause scalability problems. I like to write a lot of my code in the database, and I would never be able to move to mysql from postgres, since mysql just doesn't support half the stuff postgres does. I might be able to migrate to sql server, db2, or oracle, but not the other way.
