Michael Stonebraker

Dr. Stonebraker has been a pioneer of database research and technology for more than forty years. He was the main architect of the INGRES relational DBMS, and the object-relational DBMS, POSTGRES. These prototypes were developed at the University of California at Berkeley where Stonebraker was a Professor of Computer Science for twenty-five years. More recently at M.I.T. he was a co-architect of the Aurora/Borealis stream processing engine, the C-Store column-oriented DBMS, the H-Store transaction processing engine, the SciDB array DBMS, and the Data Tamer data curation system. Presently he serves as Chief Technology Officer of Paradigm4 and Tamr, Inc.

Professor Stonebraker was awarded the ACM System Software Award in 1992 for his work on INGRES. Additionally, he was awarded the first annual SIGMOD Innovation award in 1994, and was elected to the National Academy of Engineering in 1997. He was awarded the IEEE John Von Neumann award in 2005 and the 2014 Turing Award, and is presently an Adjunct Professor of Computer Science at M.I.T, where he is co-director of the Intel Science and Technology Center focused on big data.

Read Blogs

Universal Relation Data Modelling Considered Harmful

(I) Introduction The concept of a universal relation (UR) was explored extensively by DBMS theoreticians in the early 1980s following an initial paper on the topic in 1982 by Jeff Ullman et. al. [1]. The UR model deals with a collection of tables, T1, … ,Tn. Assume there is a unique join path, P, that connects all the tables. Clearly, a relational view, V(P) can be constructed based on P. The UR...
Business Transformation

Comparison of JOINS: MongoDB vs. PostgreSQL

In this blog post we review the JOIN capabilities in both MongoDB and Postgres. The conclusion is that MongoDB joins are very brittle (when things change, application programs must be extensively recoded), and often MongoDB offers very poor performance, relative to Postgres. We begin in Section 2 with MongoDB support for joins, then continue in Section 3 with the corresponding capabilities in Postgres. In Section 4 we show why MongoDB joins are brittle, and finally in Section 5 we consider join performance in both systems.

"Schema Later" Considered Harmful

The various No SQL vendors tout the benefits of “schema later” in their promotional materials and in other places. In this blog post, we argue that schema later is a bad idea, and should be avoided, especially for important data that you care about. The argument in favor of “schema later” is that it makes the “out of box” experience much better for an initial user. In other words, a user can...

Those Who Forget the Past Are Doomed to Repeat It

Over the past decade, there have been a number of DBMSs introduced (typically labeled as NoSQL) which utilize a network or hierarchical data model. MongoDB and Cassandra come immediately to mind as examples. Some such systems support networks through the concepts of “links” and some support hierarchical data using a nesteddata model often utilizing JSON. In my opinion, these systems have not...