Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.
by Anonymous Coward writes:
on Friday May 15, 2009 @08:36AM (#27964633)
Yes. And Slony is also difficult to administer and easy to break.
Postgres is very much lacking a simple replication solution. If you're in the cloud, it's far more likely you're going to have many many smaller database spread across many machines. You need to be able to bring up groups of 3 (minimum) machines that cluster an entire database quickly and easily. You don't need all the flexibility of Slony, and you certainly don't need it's administration headaches.
I can't even imagine trying to administer 10's of databases with Slony, not to even think about 100's or more.
PostgreSQL (Score:4, Insightful)
Just bite the bullet and port to it. In the process, you may have to learn a bit about how databases are actually supposed to work, but that's probably good for you.
Re: (Score:3, Informative)
It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.
Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.
What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.
Re: (Score:4, Interesting)
Slony-I is asynchronous. Read postgres' excellent documentation [postgresql.org] for some other possibilities.
You also get more flexibility; want to replicate your "current" tables but keep your "history" tables only on the master? Want to chain slaves to slaves instead of all slaves to one master? Want a special search database (you can have transactions and fulltext search at the same time) that only contains the ts_vector (fulltext search index) tables? Slony lets you do all of those.
Re:PostgreSQL (Score:2, Informative)
Yes. And Slony is also difficult to administer and easy to break.
Postgres is very much lacking a simple replication solution. If you're in the cloud, it's far more likely you're going to have many many smaller database spread across many machines. You need to be able to bring up groups of 3 (minimum) machines that cluster an entire database quickly and easily. You don't need all the flexibility of Slony, and you certainly don't need it's administration headaches.
I can't even imagine trying to administer 10's of databases with Slony, not to even think about 100's or more.