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 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.
I'm pretty skeptical of this approach. Cross platform development is a pain in the ass, whether we're talking databases or operating systems. I say pick the most powerful database you can and marry it. Use its features to the fullest and ignore portability. I suggest db2 or oracle.
abstraction is "the right thing to do" (tm).
Why not? The free versions exceed postgresql. If you succeed and face heavy load, then you just throw some money at the problem rather than blow hundreds of man-hours fidling with the hacks people use to scale the free DBMSes.
See http://www.commandprompt.com/support/ for an example, or http://pgexperts.com/services.html
This goes double if you are considering commercial products.
For various reasons we are forced to use $Vendor, but we are not a commercial shop and we always have the fear factor that $Vendor will price us out (they occasionally try it on by "forgetting" our academic discount). We hid all the DB interactions in two layers (one to hide the relational nature of the database, and the other to hide the specific implementation). As a result, I am in the position to tell $Vendor "How much? Well, you can give us this price or we can move to postgress - either is fine by me". And mean it. And they can tell.
PostgreSQL tends to be what is favored by people here. I used to use it for everything until I tried to set up a replicated cluster with it. PostgreSQL's replication is severely lacking. Slony-I, the most mature of the bunch, is very difficult to set up (with many steps needed for every single table) and a lot slower than MySQL's replication (due to its use of SQL and triggers rather than binary log shipping as well as the fact that its design causes communication costs to grow quadratically).
However, PostgreSQL's query planner is a lot better than MySQL's (especially if you're doing something like subqueries) and I find that complex queries run decently faster. The community process is also a lot more attractive.
To address the Oracle question:
Oracle cannot withdraw InnoDB. It's GPL licensed. Anyone can fork it should Oracle decide they don't want to play ball - just as anyone can fork MySQL. In fact, there are already forks underway including Drizzle. So, that isn't a big deal. The bigger deal would be if Oracle decided to halt future development. I'm guessing they won't since it would simply mean they would loose control to the community that still has rights to the GPL'd code.
In the end, don't worry about this issue. It distracts from what is really important: actually creating something. They both work fine. There are plenty of abstractions that will allow you to create code that will work with either with no modifications. Do that, build your application, and let the pundits from either side debate this issue until they're blue in the face while you're actually creating useful things.