Your next RDBMS .. or .. How projects fail (Score 1)

I think you hit the proverbial nail on its proverbial head with your last sentence:

Any time I have needed to use databases, the open-source solutions have done fine...

In many --even most-- cases, the high-availability and extraordinary scalability of Oracle aren't only not necessary but downright overkill. This is true because most of us don't build air traffic control systems, massive financial services transactional systems, and the like. You don't have to know much about databases to realize that at 3TB with 10,000 transactions per minute, Oracle will outperform PostgreSQL. At this level of activity, the Oracle license is most likely considered nominal to whoever is footing the bill for the project. However, at 4GB with 10,000 transactions per hour, you might find the runtime difference between PostgreSQL and Oracle not enough to justify the expense.

Incidentally, don't be fooled by the mythical status of Oracle (the database) and Oracle (the company):

• Oracle crashes, corrupts tablespaces, and is, in general, a high-maintenance mistress. If you can afford her (and that goes WAY beyond the initial license), she's great.
• Oracle's support is as hit and miss as anyone else. True, you may always get a warm body to answer the phone, but that may be all you get. (I have more anectdotal evidence of this than I care to share.)
• Oracle has a well-documented history of, well, uh, exaggerating when it comes to performance, features, and whatnot.
• People have gotten fired for recommending Oracle. I've seen it happen. (Not me, though, I've been fired for recommending PostgreSQL.)

But to get mired in this debate is not only to miss the point, but to engage in the sort of futility that causes projects to fail. Smart projects minimize technology risk. In general, the best way to do this is to build systems that are platform-agnostic.

Too many project managers/sponsors (especially in the enterprise) are engaged in the delusion that their project actually warrants a massive Oracle cluster, four-way Sun Enterprise E10000's, three Oracle DBAs, a posse of Java/EJB consultants, 30 seats of PVCS, 10 seats of JBuilder enterprise, and a partridge in a pear tree. Ask this captain of information technology what he's assembled this crack team to do and he'll likely respond with 'A custom CRM solution', or some such. This, of course, is stupid, and what's worse it's bad business. Naturally no regular reader of Slashdot would engage in such poor behavior.

The opposite of this project is the smart IT guy who realizes that the business (or marketing department for commercial developers) never knows what they want, how big the user base will be, or even what kind of cream cheese to put on their bagel. To compensate, he starts building a solution using the lowest-cost solutions that will still allow him to scale. In the case of the database, there is no reason NOT to use PostgreSQL with ANSI-SQL through a database-independent interface (such as jdbc) during development. In some cases, it may even be appropriate to continue to use PostgreSQL until the production environment warrants conversion to a more scalable, available solution.

This philosophy applies equally to hardware, tools, third-party libraries, configuration management, or even IT talent. If you're looking at a new project and someone is telling you that you need a bunch of high-priced licenses and assets at the outset, examine the rationale behind these claims carefully, chances are you don't (yet).

Art Gillespie