Database preferences and product selection methodolgy

I recently stumbled across an interesting weblog post by a DBA who expresses a strong preference for Oracle over PostgreSQL. I thought I'd respond to it with a few thoughts here, not so much because of the opinion expressed as the reasons given for it.

There are certainly plenty of areas where Oracle is a better technical choice than Pg for the job, so someone preferring Oracle isn't overly surprising or controversial. What surprises me is that the author expressed such a blanket opinion without apparent concern for use-cases or needs, instead appearing to assert that Oracle is universally better and that Pg is a second-rate Oracle clone. The preference seems to be not so much for technical reasons or need-fit reasons as political/ideological ones.

Product selection, values, and selection methods

I think this is a worldview/culture difference as much as anything. If you or your management want "somebody to sue if it breaks" and a single organization to assign blame to, Pg isn't for you. If your management always wants to buy "the market leader" irrespective of other concerns, Pg isn't for you. If you want to use the same product for absolutely every conceivable project, no matter that consistency costs you, then Pg isn't for you. For the latter case Oracle might not be either.

On the other hand, if your organization is willing and able to evaluate its needs and requirements then select products based on those needs, you might find that Pg is a good fit for some (though perhaps not all) the roles or projects you need a DB for. This might mean that you need to support more than one database if you find that you have a job Pg isn't well suited to. There certainly are things Pg doesn't do well. On the other hand, it also means that you may be able to save eye-popping sums in license fees by using Pg in roles where it is a good fit.

For example: If you want a multi-master shared-storage cluster on a SAN, Pg is a poor fit for that role. Similarly, if you want really strong XML and XSLT support in-database, Pg will probably not be good for you. On the other hand, if you need a high-performance master plus some read-only replicas for a system handing geographic information, that's one of the many areas where Pg is an ideal fit. For tasks where reliability and good performance are important and a solid relational database is required, Pg is a strong contender. If you determine what you need you can make informed decisions about what product(s) fit those needs on a case-by-case basis.

Support

As for support - personally, I've had nothing but bad experiences with single-vendor support. I've had particularly horrible experiences with the "support" offered by Adobe, by Quark, and by a few more specialized newspaper-industry products used at my work. I'm reduced to begging them for a fix, which they will provide according to their determination of the problem's importance and on their schedule. Support contracts have - in my experience - surprisingly little effect on this. Not only can I not fix a bug/fault in most big single-vendor software myself, but the vendors never provide debugging symbol data, so I can't even hook up a debugger and get a backtrace to analyse a crash to see what's causing it so I can try to work around it locally. Microsoft is one of the few vendors who provide debug symbols, and even then not for all their products.

By contrast, when working with Pg I've usually seen bugs reported by me or others fixed in hours, not days. For crashes (and yes, crash bugs do turn up) I can send off a complete backtrace showing exactly what went wrong and where, simplifying support and bug fixing immensely. In one case (multiple keys in a JDBC keystore using client cert auth) I landed up fixing it myself and sending in a patch that was included in the next version. I would never have been able to do that without the sources and debug symbols.

Sometimes a fix will hit git master minutes after a mailing list post points an issue out, typically along with additional regression tests to catch it if it comes up again. A few key committers (you know who you are) are absolute heroes in this area. Of course, responses do depend on whether there's anyone interested in the problem, how busy everybody is, etc ... and if you're using Pg for free you have no right to demand anything more.

Because you may not want to be dependent on the attention span of mailing list readers, paid support is available from numerous outfits, including several run by major Pg core contributors. By signing up with them, you get to assert your priorities and do things on your timelines.

What that means is that you have solid support guarantees if you want them, but the freedom not to take them if you don't need them for a particular deployment role.

Pg as a poor Oracle clone

I'm afraid this is just misinformed. Pg *does* try to maintain a degree of Oracle compatibility for ease of porting and because users want it, but it is not and has never been an Oracle clone. Please see http://www.postgresql.org/about/history.

In conclusion

Personally, I think product ideology is dangerous, no matter which product is your idol. Select according to your needs.