The out-of-the-box configuration for Postgres has a lot of performance issues compared to MySQL. I'm not really sure what scenario it's designed for, but I've a

The out-of-the-box configuration for Postgres has a lot of performance issues compared to MySQL. I'm not really sure what scenario it's designed for, but I've always needed to make changes for my use case. Postgres' query optimizer is a lot smarter than MySQL's. For trivial queries this is irrelevant, but your queries have to get a lot more complicated before they'll confuse Postgres relative to MySQL. Postgres doesn't (that I know of) have multiple storage engines. You don't get something like MyISAM where you can trade transactional safety for better read performance. This is both a plus and a minus: you only have one option but all of the storage engine-related developer time has gone into fixing up that one option. If you're experienced with MySQL, Postgres will probably come off as ... pedantic. Historically it as a project has cared a lot more about data integrity than MySQL has. That means a lot of the things you could "get away with" in MySQL aren't allowed. In general this is a good thing, but it also can get irritating. In general, Postgres seems to expect you to know/care a lot more about databases. MySQL is set up so that many use cases work well enough without tuning it, but the flipside of that situation is that the average community member probably doesn't know as much about configuring it to get better performance. If you're looking to treat your database as a big heap that stores your data and more or less efficiently regurgitates it (i.e. 90% of web programming's use of databases) then Postgres is likely going to need too much babying for the value it provides. If you actually need to deal with very complex queries and can afford to care deeply about your data, I'd have a hard time recommending anything else.