I've worked with expensive SQL Server and Oracle setups for most of my career. I've defended them viciously against all comers and contrarians. I've participated in late-night guerilla flame wars and drunken bar brawls. And I've sought out with relentless tunnel vision those pieces of propaganda which support my foregone conclusion: that SQL Server and/or Oracle are (or were) the best choices for the organization.
I used to be a commercial database advocate.
These databases have put food on my table for a dozen years, you see. I am (or was) what you might call an entrenched practicioner, not necessarily an expert, but a practicioner. And in the manner of entrenched practicioners around the world, I've treated you heretics with the sadistic undercutting and poisonous rancor you've deserved!
"MySQL?" I would sneer. "PostgreSQL? Thanks, but this a serious project. We need a database we can depend on."
Ahem.
The number of times I performed due diligence to determine if, in fact, SQL Server/Oracle was the best choice not for me, but for the team, the client, the employer, the organization?
And if I had performed said due diligence, what would I have learned? Just two things:
- SQL Server and Oracle are, indeed, excellent databases. (Okay, we already knew this.)
- SQL Server and Oracle are the wrong choice for 95% of data storage needs, including at the enterprise level.
Nowadays I like to think of SQL Server and Oracle as the Death Stars of the relational database universe. Extremely powerful. Monolithic. Brilliant. Complex almost beyond the ability of a single human mind to understand. And a monumental waste of money except in those rare situations when you actually need to destroy a planet.
And I've watched two dozen companies (at least) hemorrhage money on databases they don't need, impacting and obfuscating their bottom line with ornate Hobbesian licensing schemes, perpetuating the Fallacy of Brand-Name Software:
All other things being equal, and assuming you have the budget, always prefer an expensive well-trimmed commercial product like [insert commercial product name here] to cheaper analogues such as [insert open-source or reasonably-priced product here]. The guys over in the XYZ project used [expensive commercial product], our internal XYZ uses [expensive commercial product], ergo, new company-wide policy: use [expensive commercial product]. Sure, at $89,000 a license, [expensive commercial product] is a little expensive, but who are we kidding? We spend [insert ridiculous amount of crazed-monkey-sex Monopoly money here] on IT each and every year.
Well sure, you spend a ridiculous amount of money on IT. Ever wonder why?
Why commit your project, your organization, your empire, to building and maintaining a Death Star when what you really need is an X-Wing fighter, an AT-AT, or at best, a Star Destroyer? Especially given that:
- The performance of properly configured PostgreSQL/MySQL installations can rival that of SQL Server and Oracle.
- The vast majority of applications don't need the emergent capabilities of the latest-and-greatest Microsoft and Oracle database stacks.
- PostgreSQL and MySQL are 100% free (there are commercial distributions) which means, you guessed it, no upwards-scalability curve of licensing doom. (Of course, it should be mentioned that Oracle now owns Sun and therefore controls MySQL.)
Oracle and SQL Server have richer feature sets than MySQL or PostgreSQL or Firebird or any other open-source database. They have more integrated functionality. Nobody would argue otherwise. But are developers and DBAs and the people who influence purchase decisions fully cognizant of (for example) just how rich PostgreSQL's feature set is?
An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data.
Setting PostgreSQL aside, are developers aware that MySQL has upwards of 11 million installations including such majors as Facebook, YouTube, Flickr, and Wikipedia? Well sure, everybody knows that. MySQL runs the web, right? So do we really need the Oracle/SQL Server support for four-dimensional enraged-leprechaun hypercube visualization when the data needs of most organizations are modest, and when the two leading open-sources databases have repeatedly proven their mettle?
No.
Not unless you're running a 1% sort of scenario, leveraging proprietary Oracle/SQL Server features. (In which case, you might have a different sort of problem.)
Otherwise the answer is simply: no.
But don't let that stop you! By all means, if you're on a cost-plus government contract where waste is encouraged, go ahead and shell out for those expensive closed databases. If when Microsoft or Oracle says "jump!" your organization says "how high?" go ahead and lock yourself into a costly licensing deal for top-shelf database vodka. If your organization is dominated by smooth-talking would-be technology evangelists who are pursuing a personal agenda, as is so frequently the case, then there's probably not much you can do in any case.
But if you care about money, if you believe that...
No! It's NOT okay to squander a quarter million dollars per annum on database licensing fees even though our IT budget is in the tens of millions.
...and if you have the power to actually influence purchase decisions, then use open-source databases when you can, commercial databases when you absolutely must.
Your CFO will thank you for it.*
* - Well, probably not. Such is life.
Posted by James Devlin 111 comment(s)
