Re: Humor me: Postgresql vs. MySql (esp. licensing)

On Wed, 8 Oct 2003, John Wells wrote:

> Yes, I know you've seen the above subject before, so please be gentle with
> the flamethrowers.
>
> I'm preparing to enter a discussion with management at my company
> regarding going forward as either a MySql shop or a Postgresql shop.
>
> It's my opinion that we should be using PG, because of the full ACID
> support, and the license involved. A consultant my company hired before
> bringing me in is pushing hard for MySql, citing speed and community
> support, as well as ACID support.

MySQL almost has acid support, but their failure to support data type
constraints (i.e. insert the number 8 billion in an int4 and get the
number 2^30 back when you select it, with NO WARNING of an overflow.)

Postgresql actually has a far more active community, they just don't have
as large of a marketing wing as MySQL. Keep in mind, community means the
people using it answering questions on lists to me, not seeing a new press
release every three weeks telling us how some new feature has been added.

Postgresql has community in spades, and that community is mostly people
who do things like run the .org and .info domains, not the folks who run
large text based discussion sites like slashdot.

Everytime you do to slashdot, you use one database to get there (.org is
resolved by postgresql databases) and another to display contents (mysql
runs their backend.)

When was the last time you typed in a .org domain and didn't get a
response for a site you knew existed? On the other hand, when was the
last time you went to Slashdot or Kuro5hin and got a static screen with
the login box showing because the database was down again?

Your consultant sounds like a cheer leader. I like cheer leaders, when
they have pom poms and are doing the splits, but they have no place in
deciding which technology to use.

I've recently been testing Postgresql on our new boxes for surviving
having the plug pulled in the middle of 200 simultaneous transactions. On
our old PIII-750x2 machine with SCSI drives, the database comes right back
up, no corruption. You should demand to test both MySQL and Postgresql
under those circumstances and see how each does.

Speed is a seconday concern for a database, reliability comes first, and
Postgresql has that in spades.

> My biggest concern with MySQL is licensing. We need to keep costs low,
> and last I remember the parent company was being pretty strict on "fair
> use" under the GPL. If I recall, they even said a company would have to
> license the commercial version if it were simply used operationally within
> the company.

Licensing isn't as big a deal as some would think, after all, a commercial
MySQL license if chump change compared to the support contract on a Sun
E10K or a good network switch.

Yes, I still prefer the more pure Postgresql BSD license, but it's not a
sticking point for me.

> Also, I was under the impression that Postgresql had pretty much caught up
> with MySql in the speed category...is this not the case?

Caught up? It's been much faster for a while on many things. for
instance, how long does it take for MySQL to return a dataset from a view?
Well, since that feature's not implemented, Postgresql is much faster at
that. how long does it take MySQL to fire a trigger? It doesn't have
them, so Postgresql wins there. It's like comparing a space station to a
lawn mower.

In general, MySQL is a bit faster at ultra simple queries, while
Postgresql is quite a bit faster at complex queries. The more complexity
you throw at the database, the better postgresql handles it. MySQL's lack
of features and tendency to fail silently when it should complain loudly
makes it suitable for content management, but not for transactional work
like financials / payroll / forecasting / cost benefit analyses, etc...

> Finally, ACID support in mysql always seemed kind of a hack....perhaps
> this has changed?

Not really. Firstly, you have to use innodb tables, and if you forget, it
silently forgets to remind you that you've chosen the wrong data type.

Secondly, it doesn't support any form of constraints other than
fk/pk/unique. and it doesn't support data type constraints as mentioned
above.

> Thanks for any input (armament ;) ) you can provide.

Sure, you might wanna trawl the general and advocacy archives for more
discussions in the last year or so.