May I seize the opportunity and ask why MySQL is the prototypical Open Source SQL database software (LAMP, etc.), when PostgreSQL is considered to be so much better?
I think it's due to a different focus: PostgreSQL chose to be "correct" and feature-complete, while MySQL deliberately didn't implement the full SQL standard, and went for ease of use and, arguably, the best performance.
You see this pattern all over the world, Unix versus Windows coming to mind. The best technical implementation of your software doesn't guarantee the best position in the market, even in a tech market.
It does occasionally. In my experience, however, sometimes improving a pragmatic approach requires doing things correctly from the ground up. Sometimes the performance gain is worth it, sometimes it isn't. But generally it is there.
I don't entirely disagree. What I've found is that insistence on "correctness" is often confused with insistence on "minutiae". I suppose that in my experience the latter is usually what people mean when they talk about the former. The result is often lots of wasted resources and time fussing with tiny esoteric details that the end-user will never notice.
Correctness is certainly valuable. I've also seen projects go down long paths avoiding correct correctness due to time or resource constraints only to end up with an inferior product.
I guess a better conclusion is that a good balance needs to be struck. And I suppose that's ultimately the pragmatic approach, if the "correct" approach is better, do it, if the "get it done" approach is better, do that instead.
Because idiot MBA managers have heard of MySQL but not Postgres. (Sorry -- I couldn't resist.)
The longer answer:
When the internet took off, MySQL was a lot better than Postgres in terms of stability and speed, though not in terms of features. It grabbed marketshare and "mindshare" then, and it has retained them, even though now Postgres is its superior in terms of features, concurrency, and stability. Because of the marketshare snowball effect, it also remains far easier to hire a MySQL tech and to explain MySQL to a non-technical manager.
MySQL also continues to lead in the realm of simple andd effective replication, which Postgres does not have yet, though they are working on it (furiously).
Mysql has great replication support which everyone who does webapps requires. Postgres has bolted on solutions which all don't work well for different reasons. It's really good at all the things that webapps don't tend to use when they get big though. Postgres is far the better database in terms of correctness and sometimes even in terms of speed, it's just that the web use case doesn't need real databases but replicated (fairly dumb) data stores.
I have made plenty of web applications that did not require replication. I would guess that 90%+ of web apps do not need replication due to their low profile.
i'm never quite sure how important replication is for a DB to succeed. up until recently i didn't need it, and now oracle provides master/master - so that's transparent for me. and i don't have to worry about how to setup the apps to be master/slave aware.
who really is using mysql replication. and how interesting was a master/slave setup - the only kind of replication provided up until 4.1 (2004). i would imagine if you know howto setup your apps to work with only one master, you would know about postgres.
would really be interested if any middle-sized (not slashdot) websites use mysql replication (which setup) and since when.
Easier all around. Have you ever used the MySQL Query Browser, or Administrator Client? you can view, edit create and delete all your tables w/o even knowing any SQL so it sounds like you agree.
First mover advantage applies to open source mindshare, too.
MySQL was faster and supported by PHP. MySQL stopped being faster in a relatively short time, by then MySQL already had the mind-share (and thus resource) advantage.
Exact same situation as Linux vs. BSD -- an early boost (in that case, the AT&T lawsuit) led to a long-term lead, regardless of whether that lead was otherwise warranted.
The lead of Linux over BSD has more relation to the GPL and how it is business-safe (as in it's safer to donate source to a GPL project than to a BSD one) than the AT&T lawsuit.
If company A donates software S to GPL project G, company B cannot take it and incorporate into its product P unless it's GPL and, thus, usable by A. The same safeguard does not apply to BSD projects, hence, you see companies contributing more to Linux than to BSD.
The lead of Linux over BSD has more relation to the GPL and how it is business-safe (as in it's safer to donate source to a GPL project than to a BSD one) than the AT&T lawsuit.
If it wasn't for the fact that, feature for feature, FreeBSD is generally on-par (or ahead of) Linux, that argument would hold more weight.
In fact, for a non-service organization, it's safer to donate your source code to a BSD project because you don't have to donate all of it.
See, for instance, Juniper Networks -- one of Cisco's larger competitors, they rely on FreeBSD to power their routing/switching products, and they employee a number of FreeBSD developers in the process.
Quite a lot of BSD development is commercially funded, primarily by companies that rely on the code for their own products.
Linux, however, sees considerable contributions from companies that rely on Linux for their service offerings (such as IBM) -- Linux has the mindshare advantage, and as such, a service company needs to support it.
They are both fairly mature implementations of Unix. It is expected they shown little difference in feature set.
"it's safer to donate your source code to a BSD project because you don't have to donate all of it."
Why would you have to donate all of it? I can donate parts of a program to any project I want. What I shouldn't do in this case is to assign copyright to the project maintainer. Linux kernel developers don't have to assign copyright to the Linux Foundation.
The case for Juniper is that they can simply adopt an OS, customize it as much as they want and give back to the developers that gave this to them whatever the developers they paid wrote that is not part of their secret sauce.
I think for IBM the case is to make it easier to sell xSeries and zSeries servers if they run Linux better. As for the p's, I think they prefer to sell them with AIX. I don't think their service organization benefits much from their involvement.
They are both fairly mature implementations of Unix. It is expected they shown little difference in feature set.
In that case, how has the GPL and Linux's "business friendly" license made a difference?
Why would you have to donate all of it? I can donate parts of a program to any project I want.
The GPL. The usual "if you don't distribute it, you don't have to GPL it" argument is disingenuous given that all but a few real-world use cases require distribution.
The case for Juniper is that they can simply adopt an OS, customize it as much as they want and give back to the developers that gave this to them whatever the developers they paid wrote that is not part of their secret sauce.
Yes, and this is the case for many other businesses that rely on software -- not services -- to cover their bottom line.
I think for IBM the case is to make it easier to sell xSeries and zSeries servers if they run Linux better. As for the p's, I think they prefer to sell them with AIX. I don't think their service organization benefits much from their involvement.
Fine; add a third category -- hardware vendors. Like service providers (which was IBM's primary reason for supporting Linux) hardware vendors have generally limited reason to care about the license of the operating systems they support, unless they're interested in protecting details of their hardware implementations (eg, see nvidia binary linux drivers and the regular claim that they are GPL-incompatible).
In other words, the GPL isn't business friendly, it's just something that some businesses can be agnostic about.
"In that case, how has the GPL and Linux's "business friendly" license made a difference?"
There are probably more company-sponsored developers contributing to Linux than there are FreeBSD developers. There is a rich ecosystem with companies making money out of support assurance. In the case of FreeBSD, the obvious case is like Juniper: embed and close up. They give back whatever they think is not important because they don't want to spend money maintaining.
"The GPL. The usual "if you don't distribute it, you don't have to GPL it" argument is disingenuous given that all but a few real-world use cases require distribution."
If I contribute something to a GPL project, the copyright is still mine. Nobody but me - and that is the difference that made MySQL possoble - can distribute it in violation of the GPL. Also, the rationale that IBM donates resources to Linux in order to create an advantage to their service organization simply doesn't make sense. All of Linux is open. There are no secret advantages there. The only not patently impossible scenario here is IBM somewhat steering the development of Linux in ways that favour them in the future. But this is a very long shot.
GPL incentives sharing. BSD doesn't. It's not anti-business, but anti-effort-duplication.
And, BTW, I wouldn't be surprised if the Nvidia's binary driver were more related to the bad things that could happen to Windows support for Nvidia GPUs in the future.
Honestly the deal killer for me with Postgres has always been replication. I believe they're rolling out a replication package as part of the standard distribution soonish, but previously it was stated as "not a core feature".
There were one or two commercial replication packages which I didn't get a chance to play with, but the "standard" replication for Postgres, Slony, is incredibly difficult to deal with. By comparision, MySQL's replication tends to "just work" (easier configuration, easier to diagnose & fix problems, setup, tweak, etc).
It also had a lot to do with marketing and buzz; Postgres seems to have been happy to chug along in the background while a lot of big sites like Slashdot were pushing the tool they used. Keep in mind originally MySQL was not GPL and did not ship with RedHat, the default was Postgres. I recall when MySQL changed their licensing and RedHat started shipping them, it signified a pretty rapid change in what people were using.
All things considered, everytime I use Postgres I'm fairly impressed. I've been able to pretty painlessly migrate Oracle based systems directly to Postgres with it's PL/SQL compatibility, and it's Python stored procedure stuff is useful.
... except when MySQL's replication just fails. On more than one occasion, our DBAs have had to ask engineering what to do about records which differ between the master and some slaves. Something about updates failing at the slaves after they committed on the master, which as far as I'm concerned shouldn't ever, ever, ever be possible.
Oh, I don't disagree MySQL's replication is a pain in the ass as well - but the barrier to entry is much lower and from the outward appearance (e.g. looking at it for the first time) it looks easy and functional. Slony on the other hand appears daunting from the first look.
The simple answer: Because Slashdot runs on MySQL. It's not such a bad choice for their app: very simple queries, and reads massively outnumber writes, 1000:1. Unfortunately that's about all it's suitable for.
Just talked to the #mysql people. 6.0 is dead, yes, but the plans for it will be put into a 5.x release. 6.0 is just being rethought as the roadmap as a whole is changed. 6.0 as it was is dead, but there will still be a 6.0 eventually.
Q. How does the concept with a single trunk maps to the current tree situation?
A. 5.5 becomes the trunk. 6.0, 6.1-fk and 6.1-globalization become staging trees. Alpha features are taken out of the trunk into new staging trees. The result reaches maturity state and is released as the first milestone.
http://forge.mysql.com/wiki/Development_Cycle#Appendix_B._Fr...
I'll never understand why big companies buy out an open source project when the chances are it'll just stall and loose all credibility. Who gained from that transaction, aside from the team who got their cash windfall and ran.
Due to the inherent unreliability of the Sun/Oracle acquisition of the software, my company quickly tossed MySQL for an embedded desktop dB and moved to use SQLite, haven't even bothered to look back. That was the far better choice for our application by far (and much much cheaper).
46 comments
[ 3.4 ms ] story [ 105 ms ] threadhttp://www.markleith.co.uk/?p=245
I, for one, welcome the promise of more regular releases with open arms.
:)
(This is a serious question.)
You see this pattern all over the world, Unix versus Windows coming to mind. The best technical implementation of your software doesn't guarantee the best position in the market, even in a tech market.
Correctness is certainly valuable. I've also seen projects go down long paths avoiding correct correctness due to time or resource constraints only to end up with an inferior product.
I guess a better conclusion is that a good balance needs to be struck. And I suppose that's ultimately the pragmatic approach, if the "correct" approach is better, do it, if the "get it done" approach is better, do that instead.
Because idiot MBA managers have heard of MySQL but not Postgres. (Sorry -- I couldn't resist.)
The longer answer:
When the internet took off, MySQL was a lot better than Postgres in terms of stability and speed, though not in terms of features. It grabbed marketshare and "mindshare" then, and it has retained them, even though now Postgres is its superior in terms of features, concurrency, and stability. Because of the marketshare snowball effect, it also remains far easier to hire a MySQL tech and to explain MySQL to a non-technical manager.
MySQL also continues to lead in the realm of simple andd effective replication, which Postgres does not have yet, though they are working on it (furiously).
Not everybody who does web apps needs replication.
who really is using mysql replication. and how interesting was a master/slave setup - the only kind of replication provided up until 4.1 (2004). i would imagine if you know howto setup your apps to work with only one master, you would know about postgres.
would really be interested if any middle-sized (not slashdot) websites use mysql replication (which setup) and since when.
MySQL was faster and supported by PHP. MySQL stopped being faster in a relatively short time, by then MySQL already had the mind-share (and thus resource) advantage.
Exact same situation as Linux vs. BSD -- an early boost (in that case, the AT&T lawsuit) led to a long-term lead, regardless of whether that lead was otherwise warranted.
If company A donates software S to GPL project G, company B cannot take it and incorporate into its product P unless it's GPL and, thus, usable by A. The same safeguard does not apply to BSD projects, hence, you see companies contributing more to Linux than to BSD.
If it wasn't for the fact that, feature for feature, FreeBSD is generally on-par (or ahead of) Linux, that argument would hold more weight.
In fact, for a non-service organization, it's safer to donate your source code to a BSD project because you don't have to donate all of it.
See, for instance, Juniper Networks -- one of Cisco's larger competitors, they rely on FreeBSD to power their routing/switching products, and they employee a number of FreeBSD developers in the process.
Quite a lot of BSD development is commercially funded, primarily by companies that rely on the code for their own products.
Linux, however, sees considerable contributions from companies that rely on Linux for their service offerings (such as IBM) -- Linux has the mindshare advantage, and as such, a service company needs to support it.
They are both fairly mature implementations of Unix. It is expected they shown little difference in feature set.
"it's safer to donate your source code to a BSD project because you don't have to donate all of it."
Why would you have to donate all of it? I can donate parts of a program to any project I want. What I shouldn't do in this case is to assign copyright to the project maintainer. Linux kernel developers don't have to assign copyright to the Linux Foundation.
The case for Juniper is that they can simply adopt an OS, customize it as much as they want and give back to the developers that gave this to them whatever the developers they paid wrote that is not part of their secret sauce.
I think for IBM the case is to make it easier to sell xSeries and zSeries servers if they run Linux better. As for the p's, I think they prefer to sell them with AIX. I don't think their service organization benefits much from their involvement.
In that case, how has the GPL and Linux's "business friendly" license made a difference?
Why would you have to donate all of it? I can donate parts of a program to any project I want.
The GPL. The usual "if you don't distribute it, you don't have to GPL it" argument is disingenuous given that all but a few real-world use cases require distribution.
The case for Juniper is that they can simply adopt an OS, customize it as much as they want and give back to the developers that gave this to them whatever the developers they paid wrote that is not part of their secret sauce.
Yes, and this is the case for many other businesses that rely on software -- not services -- to cover their bottom line.
I think for IBM the case is to make it easier to sell xSeries and zSeries servers if they run Linux better. As for the p's, I think they prefer to sell them with AIX. I don't think their service organization benefits much from their involvement.
Fine; add a third category -- hardware vendors. Like service providers (which was IBM's primary reason for supporting Linux) hardware vendors have generally limited reason to care about the license of the operating systems they support, unless they're interested in protecting details of their hardware implementations (eg, see nvidia binary linux drivers and the regular claim that they are GPL-incompatible).
In other words, the GPL isn't business friendly, it's just something that some businesses can be agnostic about.
There are probably more company-sponsored developers contributing to Linux than there are FreeBSD developers. There is a rich ecosystem with companies making money out of support assurance. In the case of FreeBSD, the obvious case is like Juniper: embed and close up. They give back whatever they think is not important because they don't want to spend money maintaining.
"The GPL. The usual "if you don't distribute it, you don't have to GPL it" argument is disingenuous given that all but a few real-world use cases require distribution."
If I contribute something to a GPL project, the copyright is still mine. Nobody but me - and that is the difference that made MySQL possoble - can distribute it in violation of the GPL. Also, the rationale that IBM donates resources to Linux in order to create an advantage to their service organization simply doesn't make sense. All of Linux is open. There are no secret advantages there. The only not patently impossible scenario here is IBM somewhat steering the development of Linux in ways that favour them in the future. But this is a very long shot.
GPL incentives sharing. BSD doesn't. It's not anti-business, but anti-effort-duplication.
And, BTW, I wouldn't be surprised if the Nvidia's binary driver were more related to the bad things that could happen to Windows support for Nvidia GPUs in the future.
There were one or two commercial replication packages which I didn't get a chance to play with, but the "standard" replication for Postgres, Slony, is incredibly difficult to deal with. By comparision, MySQL's replication tends to "just work" (easier configuration, easier to diagnose & fix problems, setup, tweak, etc).
It also had a lot to do with marketing and buzz; Postgres seems to have been happy to chug along in the background while a lot of big sites like Slashdot were pushing the tool they used. Keep in mind originally MySQL was not GPL and did not ship with RedHat, the default was Postgres. I recall when MySQL changed their licensing and RedHat started shipping them, it signified a pretty rapid change in what people were using.
All things considered, everytime I use Postgres I'm fairly impressed. I've been able to pretty painlessly migrate Oracle based systems directly to Postgres with it's PL/SQL compatibility, and it's Python stored procedure stuff is useful.
From what I understand (which may not be much...), long-time MySQL stalwarts would probably move to Drizzle instead of moving to MySQL 6, anyway.
Why do so many people make this mistake? It drives me crazy!