Re: Trade Study on Oracle vs. PostgreSQL

On 25/09/2010 4:55 AM, Leif Biberg Kristensen wrote:
> On Friday 24. September 2010 20.04.26 Lincoln Yeoh wrote:
>
>> Then again, does Tom ever sleep? Maybe he sleeps in the afternoon? Or
>> is that when he does intensive coding?
>
> Once there was a suggestion on this list to give Tom every other week off to
> level the competition with the other RDBMSes.
>
> That being said, the PostgreSQL mail lists is an excellent and totally free
> support channel. Speaking for myself, I've never needed any support outside
> the mail lists. And Tom is of course a great big part of that.

I couldn't agree more. I really appreciate the time and effort people
here have spent helping out. Again, Tom Lane particularly so, for
amazing patience, psychic debugging skills, and endless willingness to
help anybody and everybody.

I try to contribute my time and rather more meagre skills back where I
can. The more people do, the better. I'm very impressed by the
atmosphere on this list compared to the Glassfish list, Hibernate
forums, Seam forums, etc; it's actually an enjoyable list to read and
participate in, which encourages me to spend more time trying to help
people out myself.

When comparing database systems, the PostgreSQL mailing list is actually
(IMO) a significant consideration. You don't have to run the gauntlet of
ignorant L1 and L2 support people to even get an obvious bug
report+stack trace to someone who knows enough to recognise it and
understand it.

Other nice things about PostgreSQL:
-----------------------------------

The database has not only debug symbols (which you don't miss until you
don't have them) but source code, making diagnosing issues considerably
easier some of the time. Especially with decent-ish tracing present in
the Linux kernel now (prof) and with DTrace support in Pg for
Solaris/BSD this is a real blessing.

Of course you can patch it yourself, too, but you may not want to do
that. Source code is an advantage even if you never intend to modify it
and only plan to use official builds.

There are also a lot of very skilled consultants willing to do paid
support, integration, migration, upgrades, etc. They charge for their
time and expertise, but you're not paying for Oracle licenses, making
the (optional) costs rather more palatable. Some groups, 2nd Quadrant,
Command Prompt, EnterpriseDB, etc can be paid to develop enhancements to
PostgreSQL - possibly to be integrated into future versions - so you can
potentially get features/fixes you require developed if there's no broad
community interest in them. There's no guarantee your enhancements will
be accepted into the core PostgreSQL (and therefore maintained in the
main version), but you should be given a decent idea how likely
acceptance is before starting work on anything, because all these folks
contribute considerably to PostgreSQL and know the development process well.

Others have mentioned many other good things; I won't repeat their words.

Things you do NOT get with PostgreSQL:
--------------------------------------

You *don't* get somebody to sue if something goes wrong, though I'm sure
for the right money . I've never understood this desire anyway; show me
one company that's successfully* sued Oracle because something went
wrong with the database and knocked out their operations. SLAs are all
well and good, but in my (admittedly limited) experience tend not to
prevent things breaking or even get the vendor to hop-to especially quickly.

You don't get first-class Java integration in the database engine
(though you do get a good JDBC driver of course). PL/Java seems to be a
bit of a second-class citizen in PostgreSQL and has some odd
limitations. I suspect there are few reasons behind this:
- PostgreSQL is strongly process oriented. Java is rather thread-
   oriented. This mismatch is a bit painful especially when it comes to
   backend startup time, resource use, etc.
- Historically, Java has been open source but far from free. License
   restrictions have prevented its integration into Linux distros and
   the BSDs, where most of PostgreSQL's users and developers are
   focused. It's been unattractive to work with.
- PostgreSQL is pure C, with its own heirachical memory management
   code. Many C programmers dislike Java and the feeling is mutual. JNI,
   the Java Native Interface, is unpleasant to work with, adding further
   disincentive for working on PL/Java. I just don't see it being much
   fun.
So, if you need java as an in-database procedural language, don't write
PostgreSQL off, but test carefully to make sure it can do what you need.

You don't get the same level of resource monitoring and allocation
control as you do in Oracle. Want to cap user "fred" at 30% of disk I/O
and 20% of host memory? No such luck. Want to monitor and graph disk I/O
load placed on the database machine by user ID? You might be able to do
it, but you'll be rolling your own with DTrace or perf. Think about how
much of this you actually need, and whether it's critical to your
deployment. Most people seem to get by just fine, as there are decent
tools for identifying performance problems and for global tuning, just
not really much per-user limiting and reporting. Also think about how
much extra hardware grunt you can afford to throw at the problem with Pg.

You don't get shared-storage clustering like RAC. There are plenty of
replication-based clustering options though; see the wiki.





* ie: recovered a sum that covers their losses, plus their legal costs
in the lawsuit. Against Oracle's army of lawyers, I'd be surprised.


--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/