For me, the one advantage MySQL (and MariaDB, and even Apache Derby!) have over PostgreSQL is that there are versions that can be run stand-alone "out of the box" as a non-root user. PostgreSQL (AFAIK) needs to be installed, and needs to be installed as root (and you need to create a postgres user, etc.).
There is a reason why no one bothers to make an XAMPP-style "portable" version of PostgrSQL, as they have with MySQL. The reason is that this is dead-simple to accomplish even with the out-of-the-box binaries available on the PostgreSQL site.
On the PostgreSQL download page, you would download the "zip archive of the binaries", rather than the one-click installer. Unzip the archive's contents wherever you like (including on a USB thumb drive), and then refer to this 3-paragraph PostgreSQL article. It tells you to create a BAT file in your base PostgreSQL directory, cut-n-pasting these contents:
REM The script sets environment variables helpful for PostgreSQL
REM "%~dp0\bin\initdb" -U postgres -A trust
"%~dp0\bin\pg_ctl" -D "%~dp0/data" -l logfile start
ECHO "Click enter to stop"
"%~dp0\bin\pg_ctl" -D "%~dp0/data" stop
The very first time you run this script, you comment-out the bold-face "REM" line... which will initialize a fresh PostgreSQL environment, with admin user "postgres" having a blank password. Then put the "REM" comment back on that line, and you have a complete portable PostgreSQL environment that can be moved from directory to directory and machine to machine.
This information is obviously Windows-centric... but the whole "portable" concept (in the USB thumb drive sense) is Windows-centric in the first place. If you're on Ubuntu, just "sudo apt-get postgres" and then remove it when you're done tinkering! By the way, you don't need administrator privileges to use the one-click installer on Windows.
A lot of the discussion that I'm seeing in this thread has more to do with phpMyAdmin vs. pgAdminIII than with MySQL vs. PostgreSQL themselves. To be perfectly frank, if one's biggest concern is what the admin or SQL workbench tool look like... then it doesn't really matter which of these two databases you use. You'll be fine either way.
The real consideration is whether you need (or would like to explore and learn about) the more "enterprise"-y features offered in PostgreSQL. If you're interested in more enterprise-level functionality, then PostgreSQL is by far the best free game in town. If you're not really interested in that stuff, then you might as well build around MySQL since it's more commonly offered by web hosts and cloud providers.
By "enterprise"-y, I'm talking about the concept of assuming that more than one application might eventually be using your database (and that the applications might be based on more than one language or technology stack). If you are only using your database through one application, and letting its ORM framework (Java JPA, Ruby Rails, PHP Doctrine, Python SQLAlchemy, etc) be responsible for enforcing all the persistence rules and business logic, then it doesn't make much difference to you as an application developer which database lies behind the framework.
However, let's say that you have a Rails web application writing to your database on the front-end, and a Java application working with it on the back-end. Maybe you even have some Python or Perl scripts kicked off by a nightly cron job, which build reports based on the data. To give a very trivial example, let's say that one of your table columns holds "customer type", and must be one of 7 fixed values (e.g. "retail", "business", whatever). You don't want values written to that column unless they are one of the 7 allowed types.
How do you enforce that? You can make the database column an "enum" type, but a lot of ORM frameworks are notoriously bad about supporting database-native enum types. You can configure the field as an enum up in your ORM framework, and let the application enforce it. However, you have multiple applications writing to this database... so you have to duplicate that across the board. Do you really trust a model where everyone connecting to your database is supposed to bring their own enforcement along with them? What about the risk of human error, if a person directly manipulates data in phpMyAdmin and makes a mistake? Even if you do decide to take your chances... all these ORM frameworks implement enums differently. Some write numeric values to the underlying database column, some write string values, etc.
With MySQL, you would probably end up creating an entirely separate lookup table. It would have 7 rows, for the acceptable values, and that column in your first table would need to be a foreign key reference to the lookup table. I hope you were aware of the need to setup your database with InnoDB, since MySQL's default storage engine doesn't even support foreign key restraints! Assuming that you did, you are still left with a more complicated data model... and are taking the performance hit of an additional table join every time you use this table.
With PostgreSQL, you would apply a CHECK CONSTRAINT to the database column. This is standard DDL supported by all enterprise-class RDBM's, and is inexplicably ignored by MySQL. If you apply a check constraint to a table column, then the database will return an error and block any update or insert which tries to write a bad value. Your data is now safe from corruption no matter which applications (or phpMyAdmin users) try to write to it.
This is just one small example, and I could go on forever. Foreign keys, check constraints, less robust stored procedures, lacking the ability to throw exceptions from a function or stored procedure (?!?)... MySQL is pretty much designed to operate as a passive data bucket, for your application tier to take exclusive responsibility over. PostgreSQL is designed to give you 80-90% of the functionality you would pay tens of thousands of dollars for in Oracle or DB2, for free and with a much lighter footprint. Again, if you're just doing a basic isolated web app, then you may not care. But if you're interested in the option of using or tinkering with the sort of features that enterprise shops take for granted... then MySQL and PostgreSQL aren't even remotely in the same league.