Questions of speed aren't that easily settled. It depends on what your data looks like and how you use it. Note that out of the box mysql gives you table level locking and so will be dog slow if you are trying to do even simple queries against large tables if you have a lot of inserts and deletes. You can get row level locking with MySQL but I have not been impressed with the robustness of these implimentations ( there are several ways to hopelessly corrupt innodb tables, I've hit them several times, and I just wouldn't ever recommend them to anyone for any data that matters ). For that sort of lifting, postgres is a much better answer ( and, honestly, not any harder to seet up that mysql ).

Note:
- mysql had been less SQL compliant but has done a good job lately of cleaning that up a bit. But still, mysql has a way to go.
- postgres had been trickier to to adminster for replication but slony has really made things nice in that regard for postgres

The real bottom line when you are thinking about a database is a function of what your data model will be and how the database will be used. Answer that and you will know which solution will scale to your needs. And, always, if your data model is poor or your SQL is sloppy, then everything will be dog slow. Normalize your data and take the time to check expliain plans when you are comparing queries ( mysql and postgres both support this ).