The ongoing MySQL campaign

"My main question so far is: is the syntax 100% compatible?"

No, it isn't. It's probably not even 90% compatible. However, if you've stuck to the SQL standard you won't have many things - if any - to change. However, there are some very commonly used MySQL extensions (like AUTO_INCREMENT) which you must do a different way in PostgreSQL, so you must be prepared for a few changes even to fairly simple code.

(Note that there are good reasons why PostgreSQL uses sequences and the SERIAL pseudo-type instead of using AUTO_INCREMENT. It's one of those things that MySQL has but PostgreSQL doesn't implement because it's actually pretty broken in transactional systems.)

The PostgreSQL documentation is extremely complete and discusses the relationship of its syntax with the standard in the documentation for each command/function. So you can learn a lot from there. There's also a lot of information about MySQL to PostgreSQL migrations all around the 'net.

Is is just some corner cases that are not (those we probably do not use anyway)?

If you're using MyISAM tables, then you're not asking much from your database. You don't need it to be reliable or to support basic transactional features, for example. So it's fairly likely you won't have too many issues, though you'd need to handle AUTO_INCREMENT and probably move to sql-standard datatype names for a few things.

Is it comparable performance-wise?

Usually I'd just say "yes"... because MySQL and PostgreSQL have comparable performance for "serious database" uses. For some workloads and queries one is faster, for others another, but there's no clear and obvious winner. However, that's assuming you're using InnoDB tables on MySQL and are relying on transactional behaviour.

You're using MySQL in quick-and-dirty MyISAM mode, where it's not even crash-safe let alone transactional. If you don't need reasonable safety you could get comparable performance from PostgreSQL by setting fsync = off in postgresql.conf but this is extremely unsafe and will damage your database if you have an unsafe server shutdown. Just like with MyISAM there's no guarantee the database can be repaired in such a case, so you may have to restore from backups.

That's really not the right approach, though. If you want that sort of thing, stick with MySQL. It's designed for it, whereas PostgreSQL is "safety first". If you actually want your data to be safe, then you'll want to (a) Move to InnoDB tables and adapt your app so that it does all database-modifying work in transactions, then (b) port over to PostgreSQL if you want that as an option.

You'll never get the raw queries-per-second performance out of PostgreSQL that you do from MyISAM tables in MySQL. Of course, your data will never be that unsafe, either ;-) . If you're prepared to do the work to make your app smarter - let the database intelligently do work you're currently doing by reading stuff into your app and processing it app-side, etc - then you might find that you get better performance out of Pg, because it's very good at more complex and difficult queries and can often do things much faster than you can do with the data in your app.