Re: "Too far out of the mainstream"

On Wed, Sep 5, 2012 at 2:40 AM, Achilleas Mantzios <
achill(at)smadev(dot)internal(dot)net> wrote:

> On Τετ 05 Σεπτ 2012 10:51:49 Ivan Sergio Borgonovo wrote:
> > On Tue, 4 Sep 2012 19:14:28 -0700
> > Chris Travers <chris(dot)travers(at)gmail(dot)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