I hear database agnosticism treated as some great good. Your application needs a database, but is built to run on "any" relational database -- generally treating it as little more than dumb storage. The SQL standard provides a sort of common language for nearly all database products, and the vendors' insistence on touting their SQL standard compliance gives this idea more credibility. Yet in practice, database products must differentiate -- after all, they're competing products. Extra features, language quirks, performance choices, all of these determine how a given product is actually used. To make your application truly database agnostic requires you to use the absolute minimum standard applicable to all of these products. You wind up wasting most of their potential.

 Let's start with a car analogy. All cars have four wheels, some sort of engine, a steering wheel, etc. To be car-agnostic, in the manner one would be database-agnostic, you would need to ignore the back seats, the trunk, the roof, the trailer hitch, the radio, the glove box, the turning radius, braking, and acceleration abilities of the car. These are not luxuries. They're natural variations in similar products. But that's the level of standardization SQL provides. You run to the store, and find yourself holding all of your groceries in your lap on the way home because you can't assume you'll have a trunk to pile them all into. It's ridiculous! The car salesman told you his car was just like any other car, that you would know how to drive it -- and you took it to mean that you should only use the absolute bare minimum parts of the car.

 When you pick a programming language, be it Java or C or Ruby, do you refuse to use anything but the most basic statements (if, while, for, =, +) for fear that you may need to change languages next week? When you agree to deliver an application to your customer, do you feel the need to handle any and all operating systems, hardware platforms, or network topologies they could possibly already have? Do you refuse to use closures in javascript, multiple-inheritance in C++, anonymous inner classes in Java, function pointers in C, nullable integers in C# for fear that you won't be able to hire any new programmers who either know or can learn how to use them? Do you rewrite all of your utility code rather than use the glut of libraries that come built-in to your environment, or the even more bountiful add-ons provided by your peers, because those same facilities might not be available, API for API, in your next environment? Do you actively refuse to do things the way your programming environment intended, such as working around garbage collection in Java just because, should you switch to old-style C, you wouldn't have it anymore? Do you refuse to use more than one programming language because we have yet, as an industry, to come up with an ABI (Application Binary Interface) that allows any language to directly call functions in another language? Then why are you treating your database platform like you intend to return it for a full refund tomorrow? You're making it sad!

 It's highly unlikely you're even doing it correctly. Unless you're fully testing your product with a whole range of database software, all the time, you've probably strayed from the minimum standard and will only find out when a customer asks that your software work with their existing install of XYZ. It's very difficult to keep yourself inside strict limits when the environment you're in doesn't restrict you. None of these products will tell you that they know what you mean, but you really shouldn't say it that way because some other product might not get it. They'll just do your bidding, and you'll be none of the wiser. By the time you realize what you've done, you'll already be too dependent on the existing solution to change without large expenditures, yet you'll have spent all this time refusing to use any of the features that could have reduced your costs. You lose either way.

 So please. Be a power user. Pick a product for what it can do for you, and then go with it. Explore. Open the glove box. Check out the trunk. Tug on that tow-hitch. Turn up the radio. It's okay to use closures and multiple-inheritance and inner classes. It's also okay to use triggers and stored procedures and declarative referential integrity and transactions and constraints and windowing functions and updateable views and derived tables and global temporary tables and context variables and external tables and cross-database queries and custom aggregate functions and database triggers and scheduled jobs and sequences and common table expressions and recursive (connect-by) queries and NULL (yes, some people even try to refuse to use NULL) and calculated (computed-by) fields. (Whew.) Train your fellow programmers. Document your code. Proselytize to your peers. Inform your customers of your requirements; just as you tell them they need to run Windows for your solution to work, tell them what database product they'll need. There will always be integration options in a heterogeneous environment; just because you were kind enough to make your product use the same database platform as the previous vendor doesn't mean the next guy will -- integration will have to happen eventually anyway. Rather than refusing to use or understand your tools, become an expert. It's a lot easier to justify your requirement to use a given database product with neat features it has that you used, than mistakes you made that now leave you unintentionally dependent on it. Your customer will get better software for it, for cheaper. You'll still sell product. It'll be okay.

 Now, go read up on the features I listed above, see how they can help you. I've yet to find rare or exclusive features in any programming environment that weren't sometimes really beneficial.