I would suggest using the DataAccessObject pattern and the Factory pattern, both mentioned here: DAO Pattern
Basically, you can create a Interface that provides all the methods your application uses to retrieve data (e.g. MyApplicationDAO). You can then create database specific implementations of that Interface (e.g. MyApplicationMSSQLDAO, MyApplicationPostgresDAO). Use a Factory to retrieve the correct implementation (MyApplicationDAOFactory.getDAO()). Using this technique several benefits:
1) support for any number of databases (just add a new DAO implementation)
2) allows you to take advantage of database specific features rather than coding to the lowest common denominator.
3) allows easier integration of alternative datasources should the need arise (e.g. XML, LDAP, etc) since your DAO interface hides implementation details from your application. (Hint: Make sure your interface is pure and does not pass any information that would tie you to a specific data implementation)
What are the downsides?
1) More code to write
2) May be duplicating some work (queries, logic, etc) if different databases are similar enough.
(You can alleviate some of this if there are opportunities for one implementation to extend another, just be careful because forcing that relationship where it should not go can cause horrendous code and a maintenance nightmare.)
In my opinion, the benefits far outweigh the costs. I always use this approach even if I only have one implentation of a datasource to support just to make sure that I have flexibility for future changes.