(and I think it's already in the Alpha)
For more information, see the development-version documentation:
http://developer.postgresql.org/pgdocs/postgres/hot-standby....
There were already plenty of technical justifications to abandon MySQL, but the potential of dealing with Oracle sealed the business case. From past experience, Oracle was not a company whose licensing, development, or business strategy we wanted to be beholden to.
With Oracle now (nearly) owning MySQL proper, the move seems correct. There's the potential that they'll improve on MySQL, but any significant improvements will eat at Oracle sales unless they're also countered with licensing changes or other revenue-boosting strategies -- such as splitting into enterprise/open source open/closed versions.
Better to use PostgreSQL where we don't need to pay client library licensing fees, and aren't locked to a vendor.
You also had the option of using the very old public domain licensed version of the client library, provided you could find it. I believe that RedHat shipped it at one point.
It hasn't shown any advantage over MySQL in the tests done so far beyond not belonging to Oracle.
And for new projects, I do prefer PostgreSQL.
...
ducks head
Except for some engines you can choose from.
- You have to choose engines
- Some features (e.g. ACID Transactions) don't work in some engines.
I'm not sure exactly why this is a feature. In PostgreSQL (and in most sane DB software)
- You don't have to choose engines
- All features work all the time. There's no posiblity of foolery like, say, beginning a transaction and then updating two tables, then finding that one of the tables will ignore the transaction but the other won't.
That's the key. Even features which you may not need in particular scenario will add their overhead.
What if you don't need transactions in PG?
Let's not forget MySQL has engines like MEMORY, ARCHIVE, BLACKHOLE (not to mention third party engines).
I was trying to forget about MySQL and it's plethora of engines.