Re: [GENERAL] Re: Is PostgreSQL ready for mission criticalapplications?

Everyone has their own experiences, and difficulties...there are X
platforms out there that PostgreSQL supports, multiply that by however
many different hardware pieces that be thrown the standard box, and you'll
get that many different experiences...would i use it in a mission critical
box?  yes, I do on several.  have I ever had problems...to be honest,
yes...most of them at the application level.

take a look at:

http://www.pgsql.com/projects/projects.cgi?sort=name

There are ppl there working on projects such as:

Arctic and Antarctic Research Center
    - Scripps Institution of Oceanography / Frank Delahoyde

CFAR Molecular Biology Core
    - University of California San Diego / David J. Looney

Online Community Newspaper
    - Alex Wilson Coldstream Ltd / Anil Amarakoon

Camping-USA!
    - Camping-USA! / Vince Vielhaber

POS System for Retail Shop
    - PIPSE Information System Co. / Yewon Heo

Postgres Mail Database
    - National Center for Supercomputing Applications / Duane Moore

Software2Go Online Store
    - Software2Go, LLC / Eric Schnoebelen

Univ Texas @ Arlington - Engineering Distance Learning Site
    - Univ Texas @ Arlington / Charlie Lindahl

Utility Billing
    - City Of Lake Lotawana / A. Van Hook


And that is just a select listing of all the projects currently listed,
and doesn't include several hundred that I'm still enterign into the new
system...

Each one of those is mission critical to the person using it, and, in some
cases, I'd say to the ppl that they affect (Utility Billing and POS System
are the two that come to mind there)...

Any bugs/limitation of the current system can be worked around, and will
be improved in each release, as they have been to date.  Each release is
generally leaps ahead of previous releases...even the minor releases
contain changes that improve things...

Quite frankly, I think the fact that Jochen is still around *even though*
he has problems says alot about the quality of both the software and the
development processes that we've developed over the past year, and also
gives a good indication of where we are going...

If you are still hestitant, write your application in such a way that if
things get to the point that you just can't stay with PostgreSQL, you can
switch.  Use perl/dbi, so that you can switch with a simple chagne to the
connect string, its what I do...except, in my case, its to make sure that
I can do all my development work in PostgreSQL, while keepign in mind that
the end user might not feel comfortable with that, and/or to keep options
open for them in the future...so far, I've been lucky, and all my clients
have been quite happy with PostgreSQL as well...

 On Mon, 22 Nov 1999, Stephen Birch wrote:

> I have been surprised by the response to this question.  I was hoping that the
> responses would be more consistent, after all when software is unreliable it
> is generally known by all users.
>
> Although one would expect a subjective bias to the opinions, the answers
> provided in the thread are highly polarized.   Jochen Topf gave a frightening
> description of an unreliable database which gave unpredictable results.  For
> example:
>
> > The most frustrating thing is that most bugs are not repeatable or at least
> > not repeatable in a small test script that I could send in with a bug report.
> > Looking at the bug reports that come through the mailing list, there are a
> > lots of the type: X works here but not in this similar situation. This is
> > IMHO a symptom of a bad design. A recent upgrade (I think it was from 6.5
> > to 6.5.1 or something like that) helped a little bit but on the other hand
> > some query optimizations that worked before didn't work anymore.
> >
>
> This is pretty scary.
>
> However, I then read another reply only to find that Brett McCoy is converting
> "hundreds of thousands of documents" with no PostgresSQL problems at all.
> Brett indicates that:
>
> > So I think PostgreSQL is quite solid and reliable.  The only thing I think
> > that is sorely needed in PostgreSQL is referential integrity constraints
> > like foreign keys (although this can be emulated with triggers).
> >
>
> In fact, the lack of referential integrity constraints happens to be my
> biggest concern - assuming the database is reliable, something that is proving
> hard to determine.
>
> Reading on, I see that "The Hermit Hacker" (love the name) also finds the
> database to be reliable:
>
> > Odd, I've been using PostgreSQL since v1.x for exactly this same reason,
> > and we haven't had any problems with the database crashing since v6.x was
> > released.  Then again, the radius server opens/closes its connections as
> > required, instead of relynig on one persistent connection, so maybe that
> > helps, but that's just "application programming" vs backend...
> >
>
> There is a subtle implication that perhaps Jochen's problems are self
> inflicted.  In a later email, Jochen responds and asks if he is the only one
> using "advanced features" and suggests that they may be the cause of his
> problems.  However, his list of "advanced features" is a little scary since
> that are the very features that makes PostgreSQL so attractive in  the first
> place - and I fully intend to use them!
>
> So which is is guys, is this database dependable for commercial use - or is an
> academic oddity, worth watching but not using?
>
> Any other success or failure stories would be really helpful....
>
> Is PostgresSQL ready for prime time, or is it limpware?
>
> Steve
>
> -------------------------------------------------
>
> PS This thread was started in pgsql-general, I cross posted to pgsql-novice as
> I am sure that some readers of that group would be interested in this topic.
> If you want to comment, please reply to pgsql-general@postgreSQL.org, I don't
> want to fork the thread!
>
>

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org