5 ms·

I think the PostgreSQL project might become even more robust with the coming mass defection away from MySQL. Except for easy replication and the ability to expl

I think the PostgreSQL project might become even more robust with the coming mass defection away from MySQL. Except for easy replication and the ability to explain it to a know-nothing manager, MySQL has nothing on Postgres these days.

Maciek416 17y ago
Can you explain your comment about "mass defection away from MySQL"? Do you think that's something that's about to practically happen? Thanks.
- tentonova2 17y ago
  We started making plans to migrate away to PostgreSQL when Oracle embarked on a clear strategy to buy/control MySQL by purchasing InnoDB, and then Sleepycat. 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.
  - spudlyo 17y ago
    You don't need to license the client library anymore now that the BSD licensed libdrizzle exists. It's a clean room implementation of the client library written by Eric Day at Sun and is compatible with MySQL server versions >= 4.1. 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.
    - rbanffy 17y ago
      BTW, Drizzle appears to be a very good database server. I am currently evaluating it under various workloads and it seems happy. 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.
- forkandwait 17y ago
  I meant the comment mostly to be funny, but "much truth is said in jest". Yes, I think it will happen -- especially if a few of the important devs in the MySQL world get frustrated with the whole Cluster F---, make a change, and start to write about it. Quality wins, but only in the long run; it took forever for C to become the standard it rightly is, but it happened. The entire universe is finally waking up to what crap Java is, why not finally realize that MySQL has fewer features, less reliability, AND is more constrained Postgres? ... ducks head
tdavis 17y ago
Replication is coming in 8.5 :) (and I think it's already in the Alpha)
- thristian 17y ago
  The Hot Standby feature is in the recently-released PostgreSQL 8.5alpha3, and what it means is that you can have a read/write master and several read-only slaves; if the master goes down, you can start switch one of the slaves to be the new master without a restart. For more information, see the development-version documentation: http://developer.postgresql.org/pgdocs/postgres/hot-standby.html http://developer.postgresql.org/pgdocs/postgres/hot-standby....
rimantas 17y ago
MySQL has nothing on Postgres these days. Except for some engines you can choose from.
- WorkerBee 17y ago
  As far as I understand mySQL - 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.
  - rimantas 17y ago
    All features work all the time That's the key. Even features which you may not need in particular scenario will add their overhead.
    - WorkerBee 17y ago
      You might not need transactions now, but what if you need then later? If the speed difference between postgress and MySQL performance (what is that, 10%? a boundary case ) is going to kill your app, then get a 10% faster server.
      - rimantas 17y ago
        In MySQL case: switch from MyISAM to InnoDB or Falcon (ALTER TABLE table ENGINE=Engine, that's it). 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).
        WorkerBee 17y ago
        If you don't need transactions in a DB engine (PG, Oracle, MS SQL, etc), then you don't use them. I was trying to forget about MySQL and it's plethora of engines.

Maciek416 17y ago

Can you explain your comment about "mass defection away from MySQL"? Do you think that's something that's about to practically happen? Thanks.

tentonova2 17y ago
We started making plans to migrate away to PostgreSQL when Oracle embarked on a clear strategy to buy/control MySQL by purchasing InnoDB, and then Sleepycat. 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.
- spudlyo 17y ago
  You don't need to license the client library anymore now that the BSD licensed libdrizzle exists. It's a clean room implementation of the client library written by Eric Day at Sun and is compatible with MySQL server versions >= 4.1. 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.
  - rbanffy 17y ago
    BTW, Drizzle appears to be a very good database server. I am currently evaluating it under various workloads and it seems happy. 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.
forkandwait 17y ago
I meant the comment mostly to be funny, but "much truth is said in jest". Yes, I think it will happen -- especially if a few of the important devs in the MySQL world get frustrated with the whole Cluster F---, make a change, and start to write about it. Quality wins, but only in the long run; it took forever for C to become the standard it rightly is, but it happened. The entire universe is finally waking up to what crap Java is, why not finally realize that MySQL has fewer features, less reliability, AND is more constrained Postgres? ... ducks head

tdavis 17y ago

Replication is coming in 8.5 :) (and I think it's already in the Alpha)

thristian 17y ago
The Hot Standby feature is in the recently-released PostgreSQL 8.5alpha3, and what it means is that you can have a read/write master and several read-only slaves; if the master goes down, you can start switch one of the slaves to be the new master without a restart. For more information, see the development-version documentation: http://developer.postgresql.org/pgdocs/postgres/hot-standby.html http://developer.postgresql.org/pgdocs/postgres/hot-standby....

rimantas 17y ago

MySQL has nothing on Postgres these days. Except for some engines you can choose from.

WorkerBee 17y ago
As far as I understand mySQL - 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.
- rimantas 17y ago
  All features work all the time That's the key. Even features which you may not need in particular scenario will add their overhead.
  - WorkerBee 17y ago
    You might not need transactions now, but what if you need then later? If the speed difference between postgress and MySQL performance (what is that, 10%? a boundary case ) is going to kill your app, then get a 10% faster server.
    - rimantas 17y ago
      In MySQL case: switch from MyISAM to InnoDB or Falcon (ALTER TABLE table ENGINE=Engine, that's it). 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).
      - WorkerBee 17y ago
        If you don't need transactions in a DB engine (PG, Oracle, MS SQL, etc), then you don't use them. I was trying to forget about MySQL and it's plethora of engines.