Welcome to End Point’s blog

Ongoing observations by End Point people

Being at the MySQL User Conference: how Postgres fits in

I spent last week in Santa Clara attending the MySQL User Conference. Friends had clued me in that the conference was going to be a riot - with developers from the many forks of MySQL in attendance, all vying for spotlight, and to differentiate themselves from the MySQL core code.

The Oracle announcement of acquiring Sun cast an uncertain and uncomfortable light over the talks about forks, community and the future of MySQL. Many people wondered aloud what development on the core of MySQL’s code would be like now, and what would become of the remaining MySQL engineers.

Would the engineers defect to Monty’s new company? Will Oracle end support of MySQL development? How would MySQL end users feel about the changes? Would there be a surge in interest in Postgres, my favorite open source database?

Of course, it’s a bit early to tell. So, I’ve really got two posts about the trip, and this first one is about PostgreSQL, aka Postgres.

There’s a huge opportunity right now for Postgres to tell its story. Not because of a specific failure on the part of MySQL, but because the Oracle acquisition has raised the consciousness of all of mainstream tech. Developers and IT managers are taking a serious look at Postgres for new development projects, and evaluating their database technology choices with an eye toward whatever Oracle decides to do.

In this window of uncertainty is an opportunity for Postgres advocates to explain what it is that draws us to the project.

As a developer and a sysadmin, my enthusiasm for Postgres comes directly from the people that work on the code. The love of their craft - developing beautiful, purpose-built code - is reflected in the product, the mailing lists and the individuals who make up our community.

When someone asks me why I choose Postgres, I have to first answer that it is because of the people I know who are involved in the project. I trust them, and believe that they make the best technology decisions when it comes to the core of the code.

I believe that there’s room for improvement in extending Postgres’ reach, and speaking to people who don’t already believe the same things that we believe: that conforming to the SQL standard is fundamentally a useful and important goal, that vertical scaling is an important design objective, and that consistency is just as important to excellent user experience as are verbose command names and syntactic sugar extensions.

All of those issues are debated when discussing (typically by people outside of the Postgres community) how the Postgres development is prioritized and how this community works. It is inarguable that in the web space, Postgres lost the race. But the initial goal of the project, I’d argue, wasn’t necessarily to be the most popular end-user database. Now, that may have changed... :)

Meantime, the Postgres community continues to mature. There are clear constraints we need to overcome on the people side. Two that I think about frequently are the need for more code reviewers for patch review and testing, and smoothing over our prickly mailing-list reputation by getting more volunteers responding to requests for information the lists.

During a particularly raucous panel session at the Percona Performance Conference, a friend in the Postgres community commented that he was so happy that our community didn’t have the issues that the MySQL community has. And I said to him that it’s just a matter of time before we experience those issues if Postgres grows as MySQL has.

We will have issues with forks, conflicts and deep-cutting (founded, or unfounded) criticism. So, my advice to all the people I know in the Postgres community is to pay attention to what is happening with MySQL right now, because we can only benefit from being prepared.


Ethan Rowe said...

Thanks for the post, Selena.

My distaste for MySQL cannot take any schadenfreude in the MySQL community's plight; the free software enthusiast in me is too upset at a major free software player potentially getting kicked in the butt by one of the organizations the products/policies of which played a significant role in my own free software evolution.

But, to the Postgres love-in: I love Postgres for quite different reasons. It's feature set is fantastic. Is it "complete"? No. I would like to see things like PIVOT. I would like to see something that handles adjacency lists more effectively than what's out there. I would like to see servers in recovery mode able to handle SELECTs for easier, effectively master/slave replication. And so on. But the feature set that's there is beautiful. As an application developer who tries to make the most of each layer of the stack, there's simply no comparison between Postgres and the other free offerings. Given the policies, costs, bloat, and general unpleasantness of Oracle, I would much prefer the use of Postgres to Oracle. To say nothing of SQL Server.

DDL in transactions? Roll-your-own group aggregate functions? The rules system giving control over the query tree? Solid referential integrity with years' of support and improvements? I could go on, but I'll stop. Postgres rocks, period.

Joshua Tolley said...

To the budding patch reviewer, the PostgreSQL wiki's page on patch review HOW-TO is an excellent resource. You don't have to know the PostgreSQL code to do a patch review. There's plenty of work there for someone who doesn't know any C, even. The primary qualification is someone willing to find creative ways to test out new patches.

Selena Deckelmann said...

@Joshua: Thanks for the link!! I added it to the body of the post as extra encouragement to would-be reviewers.

@Ethan: Regarding pivot have you seen the contrib module "tablefunc"?

Yes, transactional DDL is awesome. There are so many features that are awesome. I tend to talk about the people because not many other people in our community do that. And, who the people are that drive a project often play a big role in how a person decides whether or not to throw their support behind a project. I don't think there's anything wrong with that -- the character of the programmers and development team is often reflected in the quality of the code.

And, having spent a little time spelunking in MySQL internals last week, the Postgres code base is absolutely incredible, easy to read and extend. More universities are discovering this and using our code base for their classes -- having students write features that they might contribute back.

Ethan Rowe said...

"Our code base".

I live in the Boston area, where the screaming multitudes talk about "our chances" at this or that series, and about how "we" did last season.

When presented with such speech, my tendency is to ignore it or, occasionally, ask if the speaker is on the team.

"Our code base" is a true statement, and thus life can be beautiful.

Robert Treat said...

I'm not sure we will have a problem with forks like mysql has, because really we've already been there. Postgres has been forked both for open source projects, commercial distributions, closed source implementations, and for internal use only systems. In fact, there has been at least 20 different versions of Postgres put out over the years, according to the wiki:

I think the thing that has helped the Postgres community is that so far, we haven't had a split of the brain trust that keeps Postgres going. This allows our community to approach the forks with the idea that as long as we/core community keep steam-rolling forward, the forks will generally be a non-issue.

Part of MySQL's issue is that they have no central community pushing things forward right now. In the past, that was always the role of MySQLAB, but between the Sun buyout and now the Oracle purchase, that leadership has wavered. Oracle is still in the best position to reclaim that leadership, but it will take some time (6 months), and they will need a more recognizable presence within the community going forward.

Selena Deckelmann said...

@Robert: Good points.

What I'm pointing out is that we haven't grown to the size of MySQL, and thus haven't had an opportunity to have, say, 100 paid developers stop working on the core code and fork an entirely new product.

Sure, the issues that lead to the forks are not necessarily ones that Postgres has. However, its good to pay attention -- both to highlight counter-examples, and so that we can feel good about continuing to do things that work for us.