I moved away from MySQL a long time ago (to finally get sub selects which weren't supported by MySQL back then), so my opinion might not really count, but usual

I moved away from MySQL a long time ago (to finally get sub selects which weren't supported by MySQL back then), so my opinion might not really count, but usually there's no day passing in which I'm not writing some query using features in Postgres that are not in MySQL. Could I avoid these features? Probably. At the cost of query readability and sometimes possibly performance and/or server roundtrips. Furthermore, for years now, PostgreSQL is adding features in places that are very interesting to my use case, so I'm usually jumping ahead to newer versions very quickly. Case in point is the new jsonb support which I'll be using to displace an old, bulky and join-heavy (performance!) system for handling custom attributes of products and of course, once you've gotten a taste of the awesome, you will never want to go back. From an operations standpoint, I wouldn't say Postgres is any harder to deal with than MySQL either, especially for smaller setups. Bigger ones are probably similar too, though I personally only have experience with bigger Postgres setups. There's nothing stopping you from trying it out: At this point, both Postgres and MySQL have proven their reliability even in big setups, so when you start your next thing, you won't ever have to be afraid that your pick of database will cause you trouble later down the road. As such, I would really stop asking questions and start using Postgres.