The State of PostgreSQL: Not So Easy to Kill

by Joe Brockmeier - Jan. 07, 2010Comments (6)

If you follow open source news at all, it's been pretty hard to ignore MySQL the last few months. With a desperate campaign to stop Oracle gobbling up MySQL, the FLOSS poster database has been front and center. As usual, the PostgreSQL community has been quietly coding away and working on the 8.5 release scheduled for the first quarter of 2010.

However, one of Monty Widenius' arguments about the vulnerability of PostgreSQL has caught the attention of the PostgreSQL community. In a comment on OStatic, Widenius says that "PostgreSQL can also be killed" by a company like Oracle:

Yes, PostgreSQL can also be killed; To prove the case, think what would happen if someone managed to ensure that the top 20 core PostgreSQL developers could not develop PostgreSQL anymore or if each of these developers would fork their own PostgreSQL project.

Greg Sabino Mullane, posting on the End Point Blog, points out how silly that argument is:

The catch comes from being able to actually stop 20 of those people from working on Postgres. There are basically two ways to do this: Oracle could buy out a company, or they could hire (buy out) a person. The first problem is that the Postgres community is very widely distributed. If you look at the people on the community contributors page, you'll see that the 32 people work for 24 different companies. Further, no one company holds sway: the median is one company, and the high water mark is a mere three developers. All of this is much better than it was years ago, in the total number and in the distribution.

In fact, 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.

It's not to say that every FLOSS project that's controlled by a single entity will go the way of MySQL. But what's happened to MySQL could happen to other projects where one company holds control over the project. Something to think about when deciding what projects to work with, adopt, and depend on in 2010.

Joe 'Zonker' Brockmeier is a longtime FLOSS advocate, and currently works for Novell as the community manager for openSUSE. Prior to joining Novell, Brockmeier worked as a technology journalist covering the open source beat for a number of publications, including Linux Magazine, Linux Weekly News, Linux.com, UnixReview.com, IBM developerWorks, and many others.

Previous: Superphone is Just A...Next: Philips Is Singing S... Browse Blog

by Jim Mlodgenski on Jan. 07, 2010

While anything can be killed with the appropriate amount force, everyone in our industry knows that we mitigate risk by eliminating single points of failure and the PostgreSQL community is setup to do just that. It is analogous in many ways to the Linux community in having a meritocracy of strong globally dispersed individuals working towards a common goal. This was a disadvantage to PostgreSQL in the early days of adoption in that there was no strong corporate presence with a marketing group like MySQL to push out the PostgreSQL message, but companies like EnterpriseDB and many others are now providing that bridge between corporate users and the PostgreSQL community that ensure the future growth of PostgreSQL.

0 Votes

by Josh Berkus on Jan. 07, 2010

Zonker,

Quick correction: the *beta* of 8.5 is due this quarter. The final probably won't be out until May-June. Depends on how long it takes us to work out the bugs in Hot Standby.

Thanks for echoing our message. We've made some choices over the years to avoid single company dominance; for example, no more than two members of the core team are allowed to work for the same company -- they have to refuse the job, or step down. Of course, we had the advantage over MySQL of being able to have a bad experience in this regard (Great Bridge's failure) and survive; we learned from that not to support egg-basket monopolization.

Mind you, I don't think the Oracle acquistion will destroy the MySQL *community*. In fact, the end of MySQL AB has effectively made the community stronger than ever by forcing people to not rely on the company for everything.

0 Votes

by an anonymous user on Jan. 09, 2010

Oh! ... Joe Brockmeier.

Game over. Regardless of what Brockmeier says in this article, nor how reasonable his assertion seems, his credibility is near Zero. -- By casting his lot with Microsoft/Novell he has sold his soul to satan himself.

So, my question to OStatic is: Why publish non-credible sources?

0 Votes

by Scott Marlowe on Jan. 09, 2010

1: nice ad hominem attack. If you've got a real point to make, feel free to actually make it.

2: The real solution to the MySQL problem is Oracle agreeing to LGPL the connect libs for MySQL 5. That would allow anyone to write software that connects to the db and not worry about GPLing their own code. People writing code for MySQL would be free to fork the base code all they wanted, and users could then use MySQL all they want without worrying about the GPL.

3: PostgreSQL is now as fast as MySQL, more reliable, more featureful, and in general a much better DB with NO licensing issues to worry about whatsoever. If you trawl the pgsql-general mailing list, there's tons of folks switching over from mysql to pgsql right now, and the trend is likely to continue to grow.

0 Votes

by an anonymous user on Jan. 09, 2010

I truly don't understand why nobody has written an independent and freely available MySQL library. The protocol is more-or-less adequately shown here: http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol.

The gaps can be filled in by the MySQL code itself, as horrendous as it is.

I know this is possible because I did exactly this for a client; write a non-blocking MySQL library in C with bindings for Lua. (This is proprietary code, though it only took a week or so of work so not hard to reproduce.) PostgreSQL of course needs no such effort because for one thing the library can already operate in non-blocking mode, but like so many others the client made the mistake of becoming dependent on MySQL, warts and all.

The best solution for all is for people to learn to write portable code. If your code is portable, then it doesn't matter whether a project disappears. If Linux, MySQL, and x86 processors disappear tomorrow, little to none of my code needs changing.

Anyhow, the fact that there are no other independent MySQL libraries just tells me that all the noise about Oracle and MySQL is just whining. If people were serious they'd get hacking. If somebody were to offer money I'd be happy to re-write a new library. (I personally don't use MySQL so have no independent incentive.)

0 Votes

by an anonymous user on Jan. 14, 2010

The MySQL Native Driver for PHP is another example of an alternative client library, but with a BSD like license.

0 Votes