How Different Is Postgresql to MySQL

Differences between PostgreSQL and MySQL for PHP developers

Is PostgreSQL support integrated just as well with PHP as MySQL is?

Yes. And maybe even better, more PHP functions available to make things very simple.

Is writing PostgreSQL queries (SQL) very similar to MySQL?

Yes, it's SQL. But you do have more advanced functionality available, like Oracle and SQL Server.

Are there any caveats to consider when choosing PostgreSQL instead of
MySQL?

PostgreSQL is not yet widespread on cheap hosting providers. But it is available.

Is PostgreSQL per definition the better solution when using GIS data?

MySQL is a joke when you need GIS queries and PostGIS (functions and datatypes in PostgreSQL) is one of the best GIS databases available in the market.

Edit:
Check these two comparisons:

SQL Server 2008/Oracle 11G/PostGIS
SQL Server
2008/MySQL/PostGIS

PostGIS has moved on to version 2.0 and PostgreSQL to version 9.1, with 9.2 upcoming.

MySQL has just a few GIS functions and lacks performance, it's not a serious option for GIS.

Postgresql vs. MySQL: how do their data sizes compare to each other?

MySQL uses MVCC as well, just check
innoDB. But, in PostgreSQL you can
change the FILLFACTOR to make space
for future updates. With this, you
can create a database that has space
for current data but also for some
future updates and deletes. When
autovacuum and HOT do their things
right, the size of your database can
be stable.
The blog is about old versions, a lot
of things have changed and PostgreSQL
does a much better job in compression
as it did in the old days.
Compression depends on the datatype,
configuration and speed as well. You
have to test to see how it's working
for you situation.

I did a couple of conversions from MySQL to PostgreSQL and in all these cases, PostgreSQL was about 10% smaller (MySQL 5.0 => PostgreSQL 8.3 and 8.4). This 10% was used to change the fillfactor on the most updated tables, these were set to a fillfactor 60 to 70. Speed was much better (no more problems with over 20 concurrent users) and data size was stable as well, no MVCC going out of control or vacuum to far behind.

MySQL and PostgreSQL are two different beasts, PostgreSQL is all about reliability where MySQL is populair.

MySQL vs PostgreSQL for Web Applications

A note to future readers: The text below was last edited in August 2008. That's nearly 11 years ago as of this edit. Software can change rapidly from version to version, so before you go choosing a DBMS based on the advice below, do some research to see if it's still accurate.
Check for newer answers below.

Better?

MySQL is much more commonly provided by web hosts.

PostgreSQL is a much more mature product.

There's this discussion addressing your "better" question

Apparently, according to this web page, MySQL is fast when concurrent access levels are low, and when there are many more reads than writes. On the other hand, it exhibits low scalability with increasing loads and write/read ratios. PostgreSQL is relatively slow at low concurrency levels, but scales well with increasing load levels, while providing enough isolation between concurrent accesses to avoid slowdowns at high write/read ratios. It goes on to link to a number of performance comparisons, because these things are very... sensitive to conditions.

So if your decision factor is, "which is faster?" Then the answer is "it depends. If it really matters, test your application against both." And if you really, really care, you get in two DBAs (one who specializes in each database) and get them to tune the crap out of the databases, and then choose. It's astonishing how expensive good DBAs are; and they are worth every cent.

When it matters.

Which it probably doesn't, so just pick whichever database you like the sound of and go with it; better performance can be bought with more RAM and CPU, and more appropriate database design, and clever stored procedure tricks and so on - and all of that is cheaper and easier for random-website-X than agonizing over which to pick, MySQL or PostgreSQL, and specialist tuning from expensive DBAs.

Joel also said in that podcast that comment would come back to bite him because people would be saying that MySQL was a piece of crap - Joel couldn't get a count of rows back. The plural of anecdote is not data. He said:

MySQL is the only database I've ever programmed against in my career that has had data integrity problems, where you do queries and you get nonsense answers back, that are incorrect.

and he also said:

It's just an anecdote. And that's one of the things that frustrates me, actually, about blogging or just the Internet in general. [...] There's just a weird tendency to make anecdotes into truths and I actually as a blogger I'm starting to feel a little bit guilty about this

PDO : How different is mysql from postgresql

I want to use Mysql on my local and PostgreSQL on production server.

No, you dont, you really don't - trust me.

I am mysql novice and have no idea on PostgreSQL.

Then pick one and stick with it. You'll have enough to manage learning one system. Both run on all the usual platforms you might meet and PostgreSQL runs on loads you probably never will. Making sure your application works on both RDBMSs will be fiddly and bug-prone.

I'd recommend PostgreSQL - it's more strict (irritating at first, pays off later) and has better standards support and advanced query planning. Having said that though, if you've only got MySQL on both systems just use that.

Comparison of database column types in MySQL, PostgreSQL, and SQLite? (Cross-Mapping)

List of things I'd do differently:

MEDIUMINT in MySQL is an odd duck (3 bytes). I would avoid it, but otherwise map it to INTEGER too.

The MySQL BOOLEAN (alias BOOL, alias TINYINT(1) ) is not compatible with the pg boolean type. You may or may not be able to port apps depending on what they use as boolean literals. In MySQL, TRUE and FALSE map to 1 and 0 integer values. It looks like the pg BOOLEAN type uses string literal notation. So apps may or may not be portable - at least it is no drop in replacement.

Finally, for the last line in your tabl I think the SQLite phrase should read:

INTEGER PRIMARY KEY AUTOINCREMENT

This is roughly equivalent to

BIGINT PRIMARY KEY AUTO_INCREMENT

in MySQL. In postgres, the SERIAL datatype results in an INTEGER column, and this will about the same as MySQL's

INTEGER PRIMARY KEY AUTO_INCREMENT

Postgres also has a BIGSERIAL type, which is the same as SERIAL but with a BIGINT type instead of an INT type.

What I missed:

I am missing INTEGER (alias INT) for MySQL. It is comparable to INTEGER in pg.
Very important omissions:
VARCHAR and CHAR. Semantically, VARCHAR in MySQL and PG, and CHAR in MySQL and PG are the same, but in MySQL these types have a much shorter maximum length. In MySQL these types can have a maximum of a little less than 64kb, in pg 1Gb (bytes). The actual length specifier is expressed in the number of characters, so if you have a multi-byte character set, you have to divide the maximum lenght by the maximum number of characters to get the theoretical maximum length specified for that characterset. In SQLite, VARCHAR and CHAR map both to TEXT

The BIT datatypes in MySQL and PG have roughly the same semantics, but in MySQL the maximum length of the BIT data type is 64 (bits)

I think the MySQL VARBINARY data type is best comparable to PG's BYTEA datatype. (but indeed MySQL's BLOB types also map to that)

The FLOAT type in MySQL should be equivalent to REAL in postgres (and REAL in SQLite too)
The DECIMAL type in MySQL is equivalent to DECIMAL in postgres, except that in postgres, the type does not impose an arbtrary limit on the precision, whereas in MySQL the maximum precision is (i believe) 70. (that is, 70 number positions)
For both MySQL and Postgres, NUMERIC is an alias for the DECIMAL type.