Many regard PostgreSQL as the state-of-the-art open source database application. Its roots go back to 1977 at UC Berkeley, and the story of how it reached its current status mirrors some of the best success stories we've heard before in open source.

If you're not familiar with PostgreSQL, this will give you a nice foundation toward better understanding this truly remarkable database.

Humble beginnings at UC Berkeley

PostgreSQL's ancestor was Ingres, developed at the University of California at Berkeley from 1977 to 1985. The Ingres code was taken and enhanced by the Relational Technologies/Ingres Corporation, which produced one of the first commercially successful relational database servers. Also at Berkeley, Michael Stonebraker led a team during the 1986 to 1994 period to develop an object-relational database server called Postgres. The Postgres code was taken by Illustra and developed into a commercial product. Two Berkeley graduate students, Jolly Chen and Andrew Yu, added SQL capabilities to Postgres during 1994 and 95 and called it Postgres95. They left Berkeley, but Chen continued maintaining Postgres95, which had an active mailing list.

Development leaves Berkeley

In the summer of 1996, it became clear that the demand for an open source SQL database server was great, and a team was formed to continue development. Marc G. Fournier, in Toronto, offered to host the mailing list and provide a server to host the source tree. One thousand mailing list subscribers were moved to the new list. A server was configured, giving a few people login accounts to apply patches to the source code using cvs.

By this point Jolly Chen had stated, "This project needs a few people with lots of time, not many people with a little time." With 250,000 lines of C code, it was easy to understand what he meant. In the early days, there were four people heavily involved: Marc Fournier in Canada, Thomas Lockhart in Pasadena, California, Vadim Mikheev in Krasnoyarsk, Russia, and me in Philadelphia, Pennsylvania. We all had full-time jobs, so we did this in our spare time. Calling this a challenge was an understatement.

Our first goal was to scour the old mailing list, evaluating patches that had been posted to fix various problems. The system was quite fragile then and not easily understood. During the first six months of development, there was fear that a single patch would break the system, and we would be unable to correct the problem. Many bug reports had us scratching our heads, trying to figure out not only what was wrong, but how the system even performed many functions.

We inherited a huge installed base. A typical bug report was, "When I do this, it crashes the database." We had a whole list of them. It became clear that some organization was needed. Most bug reports required significant research to fix, and many were duplicates, so our TODO list reported every buggy SQL query. It helped us identify our bugs, and made users aware of them too, cutting down on duplicate bug reports.

We had many eager developers, but the learning curve in understanding how the back-end worked was significant. Many developers got involved at the edges of the source code, like language interfaces or database tools, where things were easier to understand. Other developers focused on specific problem queries, trying to locate the source of the bug. It was amazing to see that many bugs were fixed with just one line of C code. Postgres had evolved in an academic environment and had not been exposed to the full spectrum of real-world queries. During that period, there was talk of adding features, but the instability of the system made bug fixing our major focus.