I've recently been through this decision process. I had v1.0 of http://shellshadow.com using mysql. I ran into one bug in my assumption about how mysql was handling unique constraints and from there started to look at postgres again.
It turned out my decision to move to postgres, which I put in production last month, was more about timing of pfg 8.3 coming to maturity than absolutes against mysql.
Here are a few points that tipped things to postgres.
1 - constraints and complex queries. MySql handles simple selects fast but has somewhat unpredictable behavior on complex queries. Including counts. Postgres generally scales in proportion to complexity of the query well.
2 - Postgres 8.3 came out. This was a big deal as it cleans up lots of things that want into 8.x.
3 - BSD-style engineering. Everything from docs to source code to make files is more rigorous with old school BSD projects. FreeBSD and Postgres are clean!!! I don't want to hammer on linux, GNU, GPL stuff too much, but to be honest, this camp is stable because of massive user base and companies put in effort to make it stable. Its a sledgehammer approach. In general I find projects like FreeBSD and Postgres to follow more rigid engineering processes. I like this in my DB ;)
4 - Full Text Search built into postgres 8.3. MySQL has FTS, sort of. Postgres prior to 8.3 had it as an add-on. You can run external Full Text Search engines like lucene or
ferret or maybe even better, sphinx. But this adds one more "engine" to manage. Most real world FTS use cases needs to have its results filtered in context of user prefs and have results filtered and sorted by other DB criteria. This means that for many FTS use cases, it is very desirable to just give the DB one big complex query and have it return things all sorted out. Using an external FTS system, you usually end up taking your FTS results and going back to the DB for further queries to filter and sort the FTS results. This adds to app code complexity. With postgres 8.3, you can do this in ways that MySQL cannot begin to compete with.
Hope these rational help. I am very happy with my decision to switch from MySQL to postgres and the process was not painful.
I thought about that too and the timing of the new relaease is a big factor in the decision making.
A year ago is would have been MySQL, just because everyone else who is big is them (e.g. paypal, google, amazon etc.) but now I really think PostgreSQL is the better choice and will be going ahead with it until I can think of a reason not to.
Here are a few points that tipped things to postgres. 1 - constraints and complex queries. MySql handles simple selects fast but has somewhat unpredictable behavior on complex queries. Including counts. Postgres generally scales in proportion to complexity of the query well. 2 - Postgres 8.3 came out. This was a big deal as it cleans up lots of things that want into 8.x. 3 - BSD-style engineering. Everything from docs to source code to make files is more rigorous with old school BSD projects. FreeBSD and Postgres are clean!!! I don't want to hammer on linux, GNU, GPL stuff too much, but to be honest, this camp is stable because of massive user base and companies put in effort to make it stable. Its a sledgehammer approach. In general I find projects like FreeBSD and Postgres to follow more rigid engineering processes. I like this in my DB ;) 4 - Full Text Search built into postgres 8.3. MySQL has FTS, sort of. Postgres prior to 8.3 had it as an add-on. You can run external Full Text Search engines like lucene or ferret or maybe even better, sphinx. But this adds one more "engine" to manage. Most real world FTS use cases needs to have its results filtered in context of user prefs and have results filtered and sorted by other DB criteria. This means that for many FTS use cases, it is very desirable to just give the DB one big complex query and have it return things all sorted out. Using an external FTS system, you usually end up taking your FTS results and going back to the DB for further queries to filter and sort the FTS results. This adds to app code complexity. With postgres 8.3, you can do this in ways that MySQL cannot begin to compete with.
Hope these rational help. I am very happy with my decision to switch from MySQL to postgres and the process was not painful.
good luck, Jon www.shellshadow.com