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.
Yeah, the results aren't pretty! The result is said to be a novella, but is actually just a weak sociology essay disguised as a story. You keep waiting for the plot or character development to start, and suddenly you reach the end and realize... there was no plot or character development!
If you haven't read Manna, then picture Ayn Rand's Atlas Shrugged. Switch John Galt's speech near the end of the book, so that it says pretty much the opposite message. Then keep the first chapter of the book, and the Galt speech at the end, and throw away the thousand pages in between where anything happens. You're pretty much left with Manna.
Don't get me wrong, I think Ayn Rand was a pretty weak philosopher too. She wrapped her ideas into controlled storytelling illustrations because she couldn't argue effectively for them otherwise. However, at least she did bother with the "storytelling" part!
... why not actually, you know, involve your wife in your family's finances while you are still alive?!?
Don't get me wrong, I believe that a healthy relationship includes privacy. I wouldn't share my personal email password with my spouse, etc.
However, your 401k and mortgage? That stuff involves marital property... why doesn't she already know where the accounts are and how to access them? Of course this is Slashdot, so I could make a ton of jokes about male and female relationships (do you really have a wife?). Regardless, it just strikes me as bizarre that someone's spouse would have no idea how to check the family's mortgage and retirement accounts. Even if you could ensure that she had the usernames and passwords after your death, do you really want her having to figure it all out from square one under those circumstances?
Of course, you also have to provide for the scenario of you and your wife dying at the same time (e.g. car accident). This is why you should have a will drafted, and an executor who knows where the accounts are. Usernames and passwords are pretty moot in that case anyway, the executor will need a death certificate to start the legal process.
I've been in software development for about 20 years, and it occurs to me that I've seen the "fat-to-thin-to-fat" cycle of hype run its course at least twice now. Predicting "The End of Fat Clients" (or thin clients for that matter) is like looking at a clock, seeing that it reads 6:00, and then declaring the death of noon.
Media in general likes a story to have "conflict" (even when it doesn't), and Slashdot these days is far worse than most. However, half the conflicts you read about here are entirely made-up. Of the three articles linked in this summary, not a single one quotes a single opponent or critic. It's just something that "Unknown Lamer" tacked on at the end, because the Slashdot-format would incomplete without something like that.
I can't really blame Slashdot, though. Reading this silly comment above (and, sadly, watching myself type a response)... there are plenty of people who take bait.
Dell, in its "infinite wisdom", have been providing both of these restore options for years now on a separate recovery partition. I am only personally familiar with Dell's, but I'm sure that other makers offer something similar. I still prefer a physical CD/DVD rather than a recovery partition approach... but other than that, I haven't heard much complaining over the past few years about this kind of functionality.
Microsoft takes an established third-party utility, and bundles something similar within Windows itself (as they do with practically every release)... and NOW this is suddenly a horrible idea and everyone is full of complaints? Hey, I'm hardly a Microsoft fanboy, but this is just childish. Where have the posts and the complaints about Dell been for the past few years?
If the code and the comments disagree, then both are probably wrong. -- Norm Schryer