Deploying and maintaining an application intended to run atop more than one RDBMS is like dancing in a minefield.
Testing:
Time <-----------> Money
You'll need to decide along a spectrum with a physical machine for each
RDBMS on one end and very, very long testing times on the other. If you
ever plan to re-visit the decision, you also need to arrange your test setup
so it can change. Remember to staff up, and that good QA people are
professionals at least as rare and experience-based as good C coders.
Whack-a-Mole
You actually need to test each and every RDBMS back-end
exactly the same
way, note what breaks, feed back into development, etc. This goes to that
O(n^2) of my earlier
post.
Extensions:
Sisyphus
If your software allows people to write extensions,
they
now have the above burden to test. Another option is for
you assume the burden for your extension writers. If you
have lots of resources, this may be an option. You'll need to explain to
your extension writers why it's so hard and takes so long to get an
extension published, though.
Red-Headed Stepchild
Your other alternative is not to care, and to have incompatible extensions
to your hard-won cross-engine software. Oops.
New Development:
Catch-22
Don't expect this to happen quickly. What your developers don't do right in
the LCD and/or Feudin' Backends (strategies outlined in previous post), your
QA people must catch and return for fixing. This process cannot be hurried.