Re: "Too far out of the mainstream" - Mailing list pgsql-general

From Chris Travers
Subject Re: "Too far out of the mainstream"
Date
Msg-id CAKt_ZfueM0uCPTuX9Y3UpJmCDg9+cYhQ_4DYJbw0og0frcF1Bg@mail.gmail.com
Whole thread Raw
In response to Re: "Too far out of the mainstream"  (Achilleas Mantzios <achill@smadev.internal.net>)
List pgsql-general


On Wed, Sep 5, 2012 at 2:40 AM, Achilleas Mantzios <achill@smadev.internal.net> wrote:
On Τετ 05 Σεπτ 2012 10:51:49 Ivan Sergio Borgonovo wrote:
> On Tue, 4 Sep 2012 19:14:28 -0700
> Chris Travers <chris.travers@gmail.com> wrote:
>
> > So people are using PostgreSQL in roles that aren't very visible
> > anyway, DBA's are usually coming to PostgreSQL from other RDBMS's,
> > and few applications are really distributed for PostgreSQL.
>
> I know a bunch of people working for huge sites that love Postgres but
> use MySQL. The main reason is they build what Postgres is famous for at
> a higher level and in a more specialized way with their own glue.
>

Postgresql has more meaning in the enterprise than in a web site.
Web Content is never critical. The world will keep turning even if some
CSS file or some article gets lost. They are meant to be transient any way.
They are not part of anything bigger.

On top of that, you also have to recognize this:  In most content management areas, data truncation, etc. is perfectly reasonable (and in fact desirable) as a way of handling data that is too long.  Most of MySQL's historical gotchas were features built in for light-weight content management.  If a comment on a blog is too long, why make the application specify truncation?  Just truncate it and get it over with.

Of course this meant MySQL couldn't move beyond content management safely until they addressed that, but now they have gone to a different niche which is again entirely different from ours:  one-app-per-database capable of customized behavior in order to achieve portability.  However since every session can set sql_mode, this approach thus again limits MySQL to that specific lowest common denominator market.  Sure you can set sql_mode = 'TRADITIONAL' but you have to cope with the fact that every other application writing to the tables could set their own sql_mode and that means you can't count on strict mode to mean anything.

For historical and software licensing reasons, however, this second one-app-per-db market is *huge.* 
 

Postgresql shines whenever data matters. I cannot imagine running our app
(single master, 80+ slaves in 80+ vessels in the 7 seas (80+ = 80 and growning)) in mysql.
We have not lost a single transaction. We have not had a single integrity issue.
All problems were due to our own fault and never postgresql's.
Runing a variaty of 7.4 / 8.3 mixture (unfortunately upgrading to 9+ is a very hard task to manage)
(now all are on 8.3) we never had any issues. And the servers run unattended,
in almost military (marine) conditions, with frequent blackouts, hardware failures due to vibration,
disk failures, mother board failures, CPU failures, memory failures.
Postgresql just delivered.

Now there's a case study.   You should write it up or even just submit what you wrote above.

And the thing is that postgresql really has no rivals either. No competitor when it comes
to full-featured OSS RDBMS. There are OSS rdbms (mysql) and full featured rdbms (DB2/Oracle)
but none besides pgsql which combines both worlds.

Also, as far as extensibility is concerned, postgresql is clearly the king.

No kidding there.

Best Wishes,
Chris Travers

pgsql-general by date:

Previous
From: David Boreham
Date:
Subject: Re: "Too far out of the mainstream"
Next
From: Chris Travers
Date:
Subject: Re: "Too far out of the mainstream"