Background:
I'm a senior developer for a consulting firm. I too have experience with DB/2, Oracle, Sybase, Adabase, and M$ SQL.
In the last few years of work I've been moving from the technical side of things to be business side ( all together now: <eewwwww> ).
I've been following PostgreSQL for a couple of years now. Absolutely love it. I have never implemented it on a business project, though. Not by any personal desire to use or not to use it. Usually the db choice is out of my hands. I cannot say personally that PostgreSQL support is amazing - ( once again, no experience at all to draw on ), however, I've been following the lists closely enough over the last few years that I believe the statement to be accurate. I can say that support services from the other vendors really aren't all that spectacular.
Perspective:
There is one factor to database choice that I haven't seen listed here. Culpability & legal retribution. I'm not a lawyer, and don't claim to be - so I welcome any corrections to the accuracy of the following. Regardless of its' legal accuracy, I can vouch for the common belief in the following thought by corporate I.T. management.
Any corporation, whether privately or publicly held, has various legal obligations to it's shareholders. Executive officers share in both the financial rewards of a successful company and in the legal responsibility that the corporation has to it's shareholders.
If a catastrophic software failure results in a high percentage of lost revenue, a corporation might be able to seek monetary compensation from a commercial vendor. They could even be taken to court - depending upon licensing, product descriptions, promises made in product literature, etc. For cases like open source projects, like PostgreSQL, there is no legal recourse available.
So - in the extreme case, if commercial Vendor V's database blows chunks, and causes company B to loose a lot of money. If Company B can prove that the fault lies squarely on the shoulders of Vendor V, Company C can sue Vendor V's a** off. Executive management isn't at fault - because they have performed due diligence and have forged a partnership with vendor V who has a legal responsibility for the claims of their product.
If, however, the database was PostgreSQL, then Company C has no legal recourse. Executive management has personally taken all responsibility for any catastrophic software failures, and therefore have put themselves in quite a precarious situation. No one else to take the blame but them!
Now frankly I know that the above scenario is extreme. I was rolling my eyes while *writing* it. But the truth is that these are the kinds of things that technical auditors would report to a Board of Directors. There is nothing wrong with executive management choosing to assume risk (outside of corporate politics, that is ). Many savvy members of management realize that the real risk is quite low. Of course, the comfort level goes way up when the database is supporting a non-vital business process - or a process that is several steps away from the revenue stream.
Still - imagine a database system with data and transactional volume the size of Google. In this case the volume of updates & inserts is much higher. Now this database is a companies' main source of revenue ( again, extreme, but we're talking examples ). Would you blame a corporate exec if he wasn't willing to place his own personal assets on the line by choosing PostgreSQL over Oracle?
BTW - Oracle & other commercial vendors handle these contingencies by buying insurance policies. If the above situation had occurred and Oracle was the vendor, then the two companies would most likely settle out of court by dealing with the insurer. I dunno exactly how the claims process works on such a beast, but I know that such policies are purchased ( and you thought the annual support fee was just to cover the support staff's salaries?). Maybe Oracle would file a claim, an adjuster would visit Oracle's customer, etc?
Closing:
I think PostgreSQL is a great database. I haven't explored it's good and bad points thoroughly enough to know what applications it serves best, and where it's weakest. I do hope to use it in enough scenarios to find out. I hope a lawyer reads this and tells me that regardless of what management thinks is true, the above is hog-wash. Until someone does, I can't ignore the fact that a commercial vendor has a legal responsibility to support the claims of their product, while an open source group does not. I think PostgreSQL specifically keeps all of their claims legitimate and reasonable, but that doesn't change the fact that if someone makes an honest mistake, there is nothing that can be done *legally* to make you correct your mistake or pay for the damage it caused.
Andrew Sullivan wrote:
Followup set to -advocacy
On Wed, Jun 26, 2002 at 12:01:18PM -0700, Dann Corbit wrote:
Customer support is also a big issue comparing free database systems
with commercial ones. I know that there are a couple groups that do
this, but that genre of businesses do not have a good track record of
staying in business. MS, Oracle, and IBM will be there five years down
the road to help.
I normally wouldn't get involved in this one, since it's the sort of
thing that turns into a flamefest. And anyway, I'm not sure -hackers
is the place for it (hence the followup). But as a lowly user, I
cannot let such a comment go unanswered.
I've used several commercial products of different kinds. I've
supported various kinds of databases. I've worked (and, in fact,
currently work) in shops with all kinds of different support
agreements, including the magic-high-availability, we'll have it in 4
hours ones. I've had contracts for support that were up for renewal,
and ones that had been freshly signed with a six-month trial.
But I have never, _never_ had the sort of support that I get from the
PostgreSQL community and developers. And it has been this way ever
since I started playing with PostgreSQL some time ago, when I didn't
even know how SQL worked. I like to have commercial support, and to
be able to call on it -- we use the services of PostgreSQL, Inc. But
you cannot beat the PostgreSQL lists, nor the support directly from
the developers and other users. Everyone is unvarnished in their
assessments of flaws and their plans for what is actually going to get
programmed in. And they tell you when you're doing things wrong, and
what they are.
You cannot, from _any_ commercial enterprise, no matter how much you
are willing to pay, buy that kind of service. People find major,
showstopper bugs in the offerings of the companies you mention, and
are brushed off until some time later, when the company is good and
ready. (I had one rep of a company I won't mention actually tell me,
"Oh, so you found that bug, eh?" The way I found it was by
discovering a hole in my network so big that Hannibal and his
elephants could have walked through. But the company in question did
not think it necessary to mention this little bug until people found
it. And our NDA prevented us from mentioning it.)
Additionally, I would counsel anyone who thinks they are protected by
a large company to consider the fate of the poor Informix users these
days. Informix was once a power-house. It was a Safe Choice. But if
I were an Informix user today, I'd be spending much of my days trying
to learn DB2, or whatever. Because I would know that, sooner or
later, IBM is going to pull out the dreaded "EOL" stamp. And I'd
have to change my platform.
The "company supported" argument might make some people in suits
comfortable, but I don't believe that they have any justification for
that comfort. I'd rather talk to the guy who wrote the code.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<[EMAIL PROTECTED]> M6K 3E3
+1 416 646 3304 x110
