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.