Database Portability, How Important is it?
How many times have you heard the mantra, "This _ will make your application portable across databases." You can fill in the blank with framework, tool, pattern, take your pick. How important is database portability in the end?
Well if you're developing a shrink wrapped product, then supporting multiple RDBMS platforms can be crucial. Your customers may be committed to any main stream, or not so main stream product and you need to meet them there.
On the other hand, if you work in a corporate IT department or as a consultant you probably know that most organizations consider the selection of an RDBMS package a strategic decision. Once the decision has occurred and the investment made it is very hard to change course. Rarely does an existing application get moved from one database to another. Besides the SQL and design considerations embedded in the application, there is the data to be migrated and the operations staff to be trained or hired.
So for the vast majority of developers database portability isn't really an issue. Most organizations have standardized on one or more RDBMS platforms. During this process they've built the expertise in running and tuning these databases. They've made significant investments in training, software and product specific tuning of applications. For the most part they have little interest and little to gain by switching from one RDBMS product to another.
I'm not advocating that every application you develop should lock you to your RDBMS vendor by using lots of vendor specific features, but sometimes these features can ease your development process. Sometimes you just need to know what the database is doing to build your application properly, and with a different database you might need to change how your application works. Understanding that Oracle is architected to provide consistent read transaction isolation through the use of their 'Rollback segments' and that other databases such as SQL Server allow you to specify dirty read can make a huge difference in the design of your application.
Many applications can probably be developed without concern for such issues, however once an application gets to a certain size you will need to start tuning it and once you're past the basics of good SQL, this will mean optimizing the applications use of the RDBMS is vendor specific ways. It is likely the physical design of an application on one RDBMS product will be different than the physical design for a second product. Differences between databases like types of indexes supported, methods to generate unique IDs, differences in locking strategies and even architecture differences such as Oracle's consistent read model.
Like everything database portability is a tradeoff between an application optimized for it's platform and an application which can be easily changed to run on another platform.