Slashdot Mirror
Why Oracle Can't Easily Kill PostgreSQL
ruphus13 writes "Claiming that 'PostgreSQL is a FOSS alternative to MySQL and hence Oracle should be allowed to pursue MySQL' is a specious argument, according to Monty Widenius. He fears that Oracle, or someone else, can easily squash PostgreSQL by just 'buying out' the top 20 developers. The Postgre community has fired back, calling that claim ridiculous. According to the article, 'PostgreSQL as a project is pretty healthy, and shows how vulnerable projects like MySQL are to the winds of change. PostgreSQL could die tomorrow, if a huge group of its contributors dropped out for one reason or another and the remainder of the community didn't take up the slack. But that's exceedingly unlikely. The existing model for PostgreSQL development ensures that no single entity can control it, it can't be purchased, and if someone decides to fork the project, the odds are that the remaining community would be strong enough to continue without a serious glitch.'"
I would like to have a list of serious companies using PostgreSQL for serious stuff...and what stuff it is PostgreSQL is doing. In my world, all you hear is "...MySQL...MySQL...", even in cases where the back-end is being handled by PostgreSQL.
Our three major DBs have about 13.4 million records combined, with enormous amounts of data about clients. PostgreSQL has never failed us. I work in the insurance business.
You forgot SQLite. It's small and good enough for most of what MySQL gets used for: simple web forms, stat counters etc.
His argument is "I was bought, therefore anybody else can be bought".
If Oracle is willing to buy 20 developers at $1 billion each, then he may be right.
EnterpriseDB is a company that offers commercial support for PostgresQL. They have salaried people on staff that contribute to the project, much like IBM, RedHat etc. contribute to the Linux kernel. So I would say Monty's scenario is about as likely as Linux going away by Microsoft or Apple paying off the to 20 kernel developers. Some people just don't get how open source works.
He sold MySQL to Sun and then left Sun.
That is factually inaccurate. He was informed that the sale had taken place once it was done. The mistake Monty made was to sell MySQL to shareholders years ago. It probably wasn't a mistake either, although there should have been a clause in the shareholder agreement about the resale of MySQL.
Like all pain, suffering is a signal that something isn't right
Richard Stallman has clarified that he believes the GPL is necessary and sufficient protection for MySQL, in direct contradiction to Widenius' call that the license should be changed and copyrights rest in some entity other than Oracle.
Eben Moglen and the Software Freedom Law Center defend the GPL even more strongly:
you had me at #!
It's not a multiuser database.
A web site is a classic multiuser scenario for an RDBMS; you have to have concurrency issues completely nailed down (ideally with row level locking and ACID).
It's also MySQL's sweet spot.
you had me at #!
What? The open source replication alternatives are good enough
You have:
* PGCluster
* Slony-I
* DBBalancer
* pgpool
* PostgreSQL table comparator
* SkyTools
* Sequoia
* Bucardo
* Mammoth Replicator
* Cybercluster
* GridSQL (shared-nothing)
All are open source and some even offer additional commercial support.
PostgreSQL did not exist in 1993-1995. It was Postgres, and Postgres95 in that timeframe. It had its own query language. It was re-written to use SQL, and then became PostgreSQL.
"To those who are overly cautious, everything is impossible. "
None of your points are relevant...
Of course Monty doesn't have the money to buy MySQL. It doesn't change the fact that he stayed completely silent on this until he got his millions. Maybe he only understood the problems of Oracle ownership then?
If Oracle has patents they can use to kill MySQL, why on earth did they need to buy it first, and how would the situation improve if they were forced to sell it? That is an absurd idea.
Of course monopoly is not good for the public. However, there is no monopoly here.
Websites that were built on (non-gpl) mysql could be in trouble if Oracle wants to fuck them. That was the risk those websites took when they decided to go with a proprietary vendor. That would suck for them, but that's how proprietary software works.
Users of GPL MySQL could be sightly inconvenienced: In the end a new community would still form around one of the forks. Again, for smart users selecting MySQL was a calculated risk of relying on a project with only one major developer.
Did I forget anything?
Anything that supports Interbase supports Firebird, which is pretty much everything. I don't think you tried very hard.
Firebird is actually way better at the things people typically use SQLite for. It can be embedded about as easily (even statically like SQLite) and works in a similar fashion with a single database file if that's what you want, etc. It performs way better than SQLite though. On par with MySQL's performance or better (but has a much better/freer license than MySQL). Plus it supports features like stored procedures and such like PostgreSQL.
It really is worth the effort.
I've last used Firebird about two years ago, so this may not be true anymore... but anyway. I've had two major problems with it.
First is documentation. There's no single place to go for it. Effectively you end up with the original Interbase manual, and then various bits and pieces which explain what was added/removed/changed, and you have to piece it all together by yourself (and there's no way to tell if you even have all the pieces in the first place). This applies to admin docs, SQL reference, and language API references.
Speaking of which, we come to the second point: API bindings are rather messy (the C one, at least). Much more so than SQLite API, for example. Among other things, I recall it requiring things like (char*) casts back and forth to reinterpret data of appropriate types, and it seems to make a lot of assumptions about sizes of various C types, so its portability to more exotic architectures would be rather suspect.
It also doesn't seem to be nearly as feature-rich as PostgreSQL. The core is solid, but e.g. standard function set is rather minimalist, and you end up rolling out your own for many occasions.
That said, Firebird/Embedded is a very nice database specifically for embedding, small and yet full-featured. If you ever missed things such as stored procedures in SQLite (and they actually make quite a lot of sense specifically for embedded DBs, where DB is tightly coupled to the application anyway), I would advise to look at FB/E.
It is in fact easy to set up and maintain -- it just requires a bit more thinking, mostly to get the authentication and such things working right, but that's a matter of editing a config file. Maintenance wise, PostgreSQL doesn't need much of that, the occasional vacuum and that's it. With auto-vacuum enabled, even that is taken care of.
I used MySQL a lot in the past, and ended up going to PostgreSQL around version 7.3, because I needed the triggers and the views. Never looked back to MySQL, PG might be slower at certain things, but at least I don't end up getting a call at 3am in the morning in the weekend informing me the database crapped itself up again, only to have to wait for myisamchk to go through near 20Gb of data.
Give it a shot and you will be enlightened :)
There is no sig...