is more difficult than it looks, since
DBMSs are multi-user software. Repeatable bugs, or “Bohrbugs,” are
easy to knock out of a system, leaving the killers, nonrepeatable errors, or “Heisenbugs.” Trying to find
nonrepeatable bugs is an exercise in
frustration. To make matters worse,
Heisenbugs are usually in the transaction system, causing customers to
lose data. This reality has generated
a severe pit in my stomach on several
occasions. Producing (and testing)
system software takes a long time
and costs a lot of money. The system
programmers who are able to do this
have my admiration. In summary,
building and commercializing a new
DBMS can be characterized by
Have a good idea (or two or three);
Make-it-happen—for a decade or so;
This brings up the obvious question: “Why would anybody want to do
something this difficult?” The answer
is the same as with a Ph.D., getting
tenure, or riding across America. I am
inclined to accept such challenges.
I spent a decade struggling to make
Postgres real and would do it again
in a heartbeat. In fact, I have done it
multiple times since Postgres.
The Present Day
I will finish this narrative by skipping to
2016 to talk about how things ultimately turned out. For those of you who were
expecting this article to be a commentary on current good (and not-so-good)
ideas, you can watch my IEEE International Conference on Data Engineering
2015 talk on this topic at http://kdb.
or the video that accompanies this
article in the ACM Digital Library.
Moultonborough, NH, present day.
Boston Bound arrived in California
the same way it left, on the roof of our
car. It now sits in our basement in New
Hampshire gathering dust. It has not
been ridden since that day at Wollaston Beach.
I am still inclined to accept physical
challenges. More recently, I decided to
climb all 48 mountains in New Hampshire that are over 4,000 feet. In a softer
dimension, I am struggling to master
the five-string banjo.
Leslie is now Director of Marketing
for an angel-investor-backed startup
in New York City, whose software inci-
dentally runs on Postgres. She refused
to major in computer science.
Illustra was successfully integrated
into the Informix code base. This system is still available from IBM, which
acquired Informix in 2001. The original
Illustra code line still exists somewhere
in the IBM archives. The academic
Postgres code line got a huge boost in
1995 when “Happy” and “Serious” replaced the QUEL query language with
a SQL interface. It was subsequently
adopted by a dedicated pick-up team
that shepherd its development to this
day. This is a shining example of open
source development in operation. For
a short history of this evolution, see
Momjian. 4 This open source code line
has also been integrated into several
current DBMSs, including Greenplum
and Netezza. Most commercial DBMSs
have extended their engines with Post-gres-style ADTs.
I now want to conclude with three
final thoughts. First, I want to mention
the other DBMSs I have built—Ingres,
C-Store/Vertica, H-Store/VoltDB, and
SciDB—all have development stories
similar to that of Postgres. I could have
picked any one of them to discuss in
this article. All had a collection of superstar research programmers, on whose
shoulders I have ridden. Over the years,
they have turned my ideas into working prototypes. Other programming
superstars have converted the prototypes into bulletproof working code for
production deployment. Skilled start-up executives have guided the small
fragile companies with a careful hand.
I am especially indebted to my current
business partner, “Cueball,” for careful
stewardship in choppy waters. Moreover, I want to acknowledge the Land
Sharks, without whose capital none of
this would be possible, especially the
“Believer,” who has backed multiple of
my East Coast companies.
I am especially indebted to my
partner, Larry Rowe, and the follow-
ing 39 Berkeley students and staff who
wrote Postgres: Jeff Anton, Paul Aoki,
James Bell, Jennifer Caetta, Philip
Chang, Jolly Chen, Ron Choi, Matt
Dillon, Zelaine Fong, Adam Glass, Jef-
frey Goh, Steven Grady, Serge Granik,
Marti Hearst, Joey Hellerstein, Mi-
chael Hirohama, Chin-heng Hong,
Wei Hong, Anant Jhingren, Greg Kem-
nitz, Marcel Kornacker, Case Larsen,
Boris Livshitz, Jeff Meredith, Ginger
Ogle, Mike Olson, Nels Olsen, Lay-
Peng Ong, Carol Paxson, Avi Pfeffer,
Spyros Potamianos, Sunita Surawagi,
David Muir Sharnoff, Mark Sullivan,
Cimarron Taylor, Marc Teitelbaum,
Yongdong Wang, Kristen Wright, and
Second, I want to acknowledge my
wife, Beth. Not only did she have to
spend two months looking at my back
as we crossed America, she also gets to
deal with my goal orientation, desire to
start companies, and, often, ruthless
focus on “the next step.” I am difficult
to live with, and she is long-suffering. I
am not sure she realizes she is largely
responsible for keeping me from falling off my own personal cliffs.
Third, I want to acknowledge my
friend, colleague, and occasional
sounding board, Jim Gray, recipient of
the ACM A.M. Turing Award in 1998.
He was lost at sea nine years ago on
January 28, 2007. I think I speak for the
entire DBMS community when I say:
Jim: We miss you every day.
1. Date, C. Referential integrity. In Proceedings of the
Seventh International Conference on Very Large
Data Bases Conference (Cannes, France, Sept. 9–11).
Morgan Kaufmann Publishers, 1981, 2–12.
2. Madden, S. Mike Stonebraker’s 70th Birthday Event.
MIT Computer Science and Artificial Intelligence
Laboratory, Cambridge, MA, Apr. 12, 2014; http://
3. Mohan, C., Haderle, D., Lindsay, B., Pirahesh, H.,
and Schwarz, P. Aries: A transaction recovery
method supporting fine granularity locking and
partial rollbacks using write-ahead logging. ACM
Transactions on Database Systems 17, 1 (Mar. 1992),
4. Momjian, B. The History of PostgreSQL Open Source
5. Stonebraker, M. The design of the Postgres storage
system. In Proceedings of the 13th International
Conference on Very Large Data Bases Conference
(Brighton, England, Sept. 1–4). Morgan Kaufmann
Publishers, 1987, 289–300.
6. Stonebraker, M. and Rowe, L. The design of Postgres.
In Proceedings of the 1986 SIGMOD Conference
( Washington, D. C., May 28–30). ACM Press, New York,
7. Stonebraker, M and Rowe, L. The Postgres data model.
In Proceedings of the 13th International Conference on
Very Large Data Bases Conference (Brighton, England,
Sept. 1–4). Morgan Kaufmann Publishers, 1987,
8. Stonebraker, M., Rubenstein, B., and Guttman, A.
Application of abstract data types and abstract indices
to CAD databases. In Proceedings of the ACM-IEEE
Workshop on Engineering Design Applications (San
Jose, CA, May). ACM Press, New York, 1983, 107–113.
Michael Stonebraker ( email@example.com) is
an adjunct professor in the MIT Computer Science and
Artificial Intelligence Laboratory, Cambridge, MA.
© 2016 ACM 0001-0782/16/02 $15.00