How PostgreSQL Rose to Fame
Pages: 1, 2
PostgreSQL global development team
In late 1996, we changed the name from Postgres95 to PostgreSQL. It is a mouthful, but honors the Berkeley name and SQL capabilities. We started distributing the source code using remote cvs, which allowed people to keep up-to-date copies of the development tree without downloading an entire set of files every day.
Releases occurred every 3 to 5 months. This time frame consisted of 2-3 months of development, a month of beta testing, a major release, and a few weeks to issue subreleases to correct serious bugs. We were never tempted to follow a more aggressive schedule with more releases. A database server is not like a word processor or a game, where you can easily restart it if there is a problem. Databases are multiuser, and they lock user data inside the database, so we had to make our software as reliable as possible.
Development of source code of this scale and complexity is not for the novice. We initially had trouble getting developers interested in a project with such a steep learning curve. However, our civilized atmosphere, and our improved reliability and performance, finally helped attract the experienced talent we needed.
Getting our developers the knowledge they needed to assist with PostgreSQL was clearly a priority. We had a TODO list that outlined what needed to be done, but with 250,000 lines of code, taking on any to-do item was a major project. We realized developer education would pay major benefits in helping people get started. We wrote a detailed flowchart of the back-end modules. We wrote a developers' FAQ to answer some of the common questions of PostgreSQL developers. With this, developers became more productive at fixing bugs and adding features.
The source code we inherited from Berkeley was very modular. However, most Berkeley coders used PostgreSQL as a test bed for research projects. Improving existing code was not a priority. Their coding styles were also quite varied.
We wrote a tool to reformat the entire source tree in a consistent manner. We wrote a script to find functions that could be marked as static, or unused functions that could be removed completely. These are run just before each release. A release checklist reminds us of the items to be changed for each release.
As we gained knowledge of the code, we were able to perform more complicated fixes and feature additions. We redesigned poorly structured code. We moved into a mode where each release had major new features instead of just bug fixes. We improved SQL conformance, added sub-selects, improved locking, and added missing SQL functionality. A company formed to offer telephone support.
The Usenet discussion group archives started touting us. In the previous year, we searched for PostgreSQL, and found many people were recommending other databases, even though we were addressing user concerns as rapidly as possible. One year later, many people were recommending us to users who needed transaction support, complex queries, commercial-grade SQL support, complex data types, and reliability. This clearly portrayed our strengths. Other databases were recommended when speed was the overriding concern. Red Hat's shipment of PostgreSQL as part of their Linux distribution quickly expanded our user base.
Every release is now a major improvement over the last. Our global development team now has mastery of the source code we inherited from Berkeley. Finally, every module is understood by at least one development team member. We are now easily adding major features, thanks to the increasing size and experience of our world-wide development team.
Bruce Momjian is writing a book about PostgreSQL for Addison-Wesley, tentatively titled, PostgreSQL: Introduction and Concepts.
Discuss this article in the O'Reilly Network Forum.
Return to the O'Reilly Network Hub.
