Re: PostgreSQL versus MySQL

On Thu, 18 Sep 2003, Steve Crawford wrote:

> On Thursday 18 September 2003 2:45 pm, Scott Holmes wrote:
> > Andrew L. Gould wrote:
> > > On Thursday 18 September 2003 04:04 pm, Sean Chittenden wrote:
> > >>> I think the below just about says it all:
> > >>>
> > >>>http://www.commandprompt.com/images/mammoth_versus_dolphin_500.j
> > >>>pg
> >
> > Not exactly the kind of image I'd like to project, especially since
> > I care about dolphins (at least non-iconified dolphins)
>
> More to the point, why is it deemed necessary to equate PostgreSQL
> with MySQL? Constantly doing that creates the image that the two are
> somehow comparable products (and that PostgreSQL has an inferiority
> complex).

I think that MySQL and Postgresql tend to occupy different problem
solution spaces. There's some overlap, but generally, I recommend MySQL
for CMS stuff, where multiple collations and built in full text indexing
are needed, and where you don't want to have to worry about tuning or
maintaining the database to get good performance. These are situations
where writes are heavily outnumbered by reads, and MySQL seems a good fit.

Postgresql is better for doing things with numbers, transactions, complex
data sets, and environments where writes make up a large portion of what
the database is doing.

Unfortunately, MySQL is busily trying to market themselves into the space
that Postgresql is so much better at, and they're doing a pretty good job
of it.

While I wouldn't wear the Elephant roasting a Dolphin TShirt to while
trying to make a "sale" of Postgresql over MySQL, I'd certainly wear it
around some of my LUG buddies, who would likely "get it".

A lot of my friends think I'm a MySQL bigot, even though when I'm
comparing MySQL to Postgresql, I'm generally pointing out one wart in
Postgresql for each one in MySQL. The lack of multiple locale support
within a single cluster, lack of an integrated vacuum method, need for
more sysadmin skill / time in maintenance and tuning, slow aggregate
performance, etc...

But often, all they're hearing are the negatives MySQL has if I'm
comparing. Why? Because they've had smoke blown up their orifices about
how great MySQL is and how it can do anything Postgresql can do now that
it has innodb tables. Why have they heard this so much? MySQL has the
budget to keep putting out press releases and paying for more people to
give speeches than Postgresql.

And MySQL doesn't fight fair in my opinion.

they still claim to have ACID compliance, an issue I've discussed with a
few of the folks from MySQL AB. To them, the C in ACID only implies fk
constraints. The fact that they ignore base type constraints (i.e. insert
8 billion into an int4 and it just sets the field to the max value an int4
can hold (2gig) and generates no error seems to not bother them.

Well, it bothers me, and it should bother their users, but they gloss
right over their own warts while pointing out ours.

To this day their crashme suite lists the maximum query size of Postgresql
as 16 Megs. I've told them many times it's not limited. Have they
changed it? No. Why? Because it looks a lot better to say MySQL has a
maximum query size of 1 meg versus 16 meg for pgsql than to admit that
it's their 1 meg versus our UNLIMITED.

While I'm not sure the TShirts are the answer, I would gladly wear one to
a LUG meeting in order to be a lightening rod for questions about pgsql.
and if it generates discussion and someone finds out they've been LIED to
by MySQL AB, all the better.

> BMW might compare its cars to Mercedes or other cars percieved to be
> in the "luxury class" but it would never compare them to Ford or
> Hyundai - to do so would create the impression that BMW and Hyundai
> are in the same class. PostgreSQL should do the same.

But we don't have the luxury of Mercedes of already owning a large chunk
of the market, and MySQL already spends a fair amount of effort targeting
us. Like it or not, many folks DO compare us to them, and will continue
to do so until they have been enlightened.

> I think the much more effective pitch is the dismissive one: sure, you
> can get a lot done with MySQL - it will probably work fine for many
> projects...Oh, but what about true transactions - are you ever going
> to need those? Or bulletproof reliability? Or true MVCC? Have you
> looked into the license restrictions? We just wanted you to know that
> when you run into these issues in MySQL, we'll be here for you.

I think the best response is the informed one. And the fair and level
headed one.

Sure, MySQL is a great storage subsystem for text and web content. I
wouldn't use it to run the payroll though, and here's why...

> Meanwhile, if we want to pick a fight we should at least pick one with
> a database in our own class.

I think MySQL is in our class in some ways, and we're in Oracle's class in
many ways. What matters is not what class we and they are in, but what
class we and they are PERCEIVED to be in. And most average users equate
us as being similar, because they don't know better. Pointing out where
each database is strong, while making it clear that Postgresql is the
heavy lifting winner is my approach, and it works quite well.

The worse thing that can happen for Postgresql is for someone to move an
application from MySQL to Postgresql if that application is better suited
to MySQL. and those applications exist. Being honest and fair will win
hearts and minds, and when they need the Saturn 4 instead of the Estes
rocket, they'll remember who to come to.