Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications? - Mailing list pgsql-general

I second this.  I am sure you will not be able to get a good idea of the
database for some people have no problems with it and some do.  My main
concern for the database used in a mission critical application is that
1)  It requires a VERY skilled DBA in both Unix and PostgreSQL
2)  There are few tools that make for ease of development and
administration.
3)  Documentation is no where near as detailed or all encompassing as a
database like Oracle.
4)  There are certain instances when the database requires a rebuild from
scratch or tape that are not related to hardware failure or disk corruption.
.5)  There are no transaction logs or redo logs that allow you to recover
the database to a point in time or handle hot online backups.
6)  It does not scale up to multi processor/multi threading very well (As I
understand it).
7)  A vacuum has to be run often (at a regular interval) taking up valuable
system resources...locking tables and sometimes just failing utterly.

Although I will say I have been very happy with it as far as what I use it
for which is web site/e-commerce development.  Usually mirroring or
distributed off of another internal coporate server :)

----- Original Message -----
From: Jochen Topf <pgsql-general@mail.remote.org>
To: <pgsql-general@postgreSQL.org>
Sent: Sunday, November 21, 1999 11:23 AM
Subject: [GENERAL] Re: Is PostgreSQL ready for mission critical
applications?


> > Stephen Birch <sbirch@ironmountainsystems.com> writes:
> > Question: Is PostgreSQL ready for mission critical applications?
> > [...]
>
> I can *not* recommend using PostgreSQL for a mission critical application.
I
> have used PostgreSQL for a reasonably sized project, where it is used as
> the central database for an ISP for administration of all users, accounts,
> hosts, ip numbers, accounting, etc. The decision for PostgreSQL was based
> on cost and features. Like you, I needed transactions and other goodies
> like triggers and notifications, that no other freely available database
> can provide.
>
> I was very pleased with PostgreSQL in the beginning, but that changed
after
> a while. PostgreSQL is not really stable, in fact it is very easy to crash
> the backend process that is handling the connection to your client and
quite
> often the other backends shut down, too. I have seen many random errors,
for
> instance sometimes loading a new stored procedure will crash the database,
> while it works the next time. Sometimes databases grow over every bound
> making the system slower and slower, the vaccum process needs hours to do
> its work and nothing except a dump and rebuild of the database helps.
>
> 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.
>
> So all this leads to my conclusion: The system is not ready for prime
time.
> If you only use some basic functionality it might be ok, but if you (like
> me) use everything from transactions to triggers, notification, user
defined
> types, stored procedurs and rules, you will probabely not be happy with
it.
>
> There is a very active developer community and I still have hope that
> PostgreSQL will make it at some point (otherwise I wouldn't be following
the
> mailing list).
>
> Jochen
> --
> Jochen Topf - jochen@remote.org - http://www.remote.org/jochen/
>
>
> ************
>
>