Because cross-database portability of SQL is still a myth. There are a lot of very, very similar flavours, and indeed the most basic of functionality is portable across dialects, however if you restrict yourself to factually portable SQL you'll very soon hit on limitations.

OTOH, a lot of the differences in the DQL and DML areas which concern the set of features common to all database engines are only superficial, ie syntactical. So assuming the database queries are properly encapsulated away from the application in a module as they should be, it wouldn't be hard to abstract away the differences between databases into several flavours of this module, of which one can then be selected by a configuration parameter.

What all that means is that it's preferrable to target a particular database at first and only refactor the business logic module that encapsulates the queries when time comes for that.

Makeshifts last the longest.