Question

Simple question – what would better for a medium/big size database with requirement for compatibility with ACID in 2012.

I have read it all (well most) about mySQL vs pgSQL but most of those posts relate to version 4,5.1 and 7,8 respectively and are quite dated (2008,2009). Its almost 2012 now so I guess we could try and take a fresh look at the issue.

Basically I would like to know if there is anything in PostgreSQL that out-weights ease of use, availability and larger developer/knowledge base of MySQL.

Is MySQL’s query optimizer still stupid? Is it still super slow on very complicated queries?

Hit me! 🙂

PS. And don’t send me to goggle or wiki. I am looking for few specific points not an overview + I trust StackOverflow more than some random page with ‘smart guy’ shining his light.

Addendum

Size of the project: Say an ordering system with roughly 10-100 orders/day per account, couple of thousand accounts, eventually, each can have several hundred to several thousand users.

Better at: being future proof and flexible when it comes to growing and changing requirements. Performance is also important as to keep costs low in hardware department. Also availability of skilled workforce would be a factor.

OLTP or OLAP: OLTP

Answer 1

EDIT: I answered this question over ten years ago. People apparently still read it and occasionally click on the upvote button. While I think that broadly the "PostgreSQL is a bit smarter than MySQL" statement is true, please don’t depend on answers this old for details about current versions of software.

---

Is MySQL’s query optimizer still stupid? Is it still super slow on
very complicated queries?

All query optimizers are stupid at times. PostgreSQL’s is less stupid in most cases. Some of PostgreSQL’s more recent SQL features (windowing functions, recursive WITH queries etc) are very powerful but if you have a dumb ORM they might not be usable.

Size of the project: Say an ordering system with roughly 10-100
orders/day per account, couple of thousand accounts, eventually, each
can have several hundred to several thousand users.

Doesn’t sound that large – well within reach of a big box.

Better at: being future proof and flexible when it comes to growing
and changing requirements.

PostgreSQL has a strong developer team, with an extended community of contributors. Release policy is strict, with bugfixes-only in the point releases. Always track the latest release of 9.1.x for the bugfixes.

MySQL has had a somewhat more relaxed attitude to version numbers in the past. That may change with Oracle being in charge. I’m not familiar with the policies of the various forks.

Performance is also important as to keep costs low in hardware department.

I’d be surprised if hardware turned out to be a major component in a project this size.

Also availability of skilled workforce would be a factor.

That’s your key decider. If you’ve got a team of experienced Perl + PostgreSQL hackers sat around idle, use that. If your people know Lisp and MySQL then use that.

OLTP or OLAP: OLTP

PostgreSQL has always been strong on OLTP.

My personal viewpoint is that the PostgreSQL mailing list are full of polite, helpful, knowledgeable people. You have direct contact with users with Terabyte databases and hackers who have built major parts of the code. The quality of the support is truly excellent.