Slashdot Mirror
MySQL Founder Starts Open Database Alliance, Plans Refactoring
Gary Pendergast writes "Monty Widenius, the 'father' of MySQL, has created the the Open Database Alliance, with the aim of becoming the industry hub for the MySQL open source database. He wants to unify all MySQL-related development and services, providing a potential solution to the fragmentation and uncertainty facing the communities, businesses and technical experts involved with MySQL, following the news of the Oracle acquisition of Sun." Related to this, an anonymous reader writes that "MySQL has announced a project to refactor MySQL to be a more Drizzle-like database." Update: 05/14 20:50 GMT by T : Original headline implied that this was a project of Sun, but (thanks to the open source nature of MySQL) it's actually Monty Widenius — no longer with Sun — leading this effort.
I didn't ask if it worked. I asked in what scenario it would be a superior option (to the well-informed application architect, of course). The only real reason you gave is that you don't know much about Postgres. That means you're not really qualified to answer the question.
Does it scale better? Does it have better security? Is it easier to manage in some way? Is there a killer feature its two closest competitors lack? Those might be actual answers to the question. "I don't know much about it" is not an answer.
It's certainly commonly perceived that Postgres will scale better, and that it has a rather complete featureset. If this is indeed the case, I can't see a reason to select MySQL for a new project. Why limit yourself?
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
MySQL is better because I know how to use it and it works well enough. If I were to switch to Postgres, then I would have to spend time learning it.
My manager would rather me move some other feature forward rather than replace database A with database B.
When we hire somebody new, it is easier to find candidates who already know MySQL. That matters too.
-ec
...I saw in one presentation their chief architect did. They had no complaints about it; apparently it scales brilliantly as long as the db schema is very simple.
For heavy-weight databases though, I gather it's not so good.
throw new NoSignatureException();
For instance if you never delete from a table there's no need to bother trying to vacuum it.
Not quite. Because of the way postgres operates (MVCC) UPDATEs will result in space appearing in table structures too. With an MVCC based DB nothing is updated in-place (actually, in any good DB nothing is updated in-place, but with MVCC this is more obviously implied by any good description of how things work with multiple distinct transactions present). When a row is updated new version is added and the old version is removed when the transaction is complete and no other transactions might refer to the old copy. This has significant advantages for some use cases and loads, and some disadvantages in other
The wikipedia page (http://en.wikipedia.org/wiki/Multiversion_concurrency_control) isn't a great description though there is a bit more relevant information in http://en.wikipedia.org/wiki/Snapshot_isolation.
I've not used postgres much in anger, so I'm no expert, but personally I thought that being able to manually schedule cleanup was a good idea performance wise.