Much of the chapter on where we failed is about problems in the academic system itself. He has some proposed solutions, but I don't know how effective (or realistic) they are. I also don't have easily expressible solutions myself.
I like this quote from the "Where We Have Failed" paper:
"We are very uncritical of systems created by the large Internet vendors to that
solve application-specific problems, which have been written, until recently, by
development teams with little background in DBMSs. As such, they have tended to
reinvent the wheel. I am especially amused by Google’s adoption and then rejection
of MapReduce and eventual consistency."
Another great read that was a collaboration of Stonebreaker, Joseph Hellerstein, and Peter Ballis is the RED (Readings in databases) book. It's been around for a while, and was updated just a few years ago - http://www.redbook.io/
I read the Red Book when I was figuring out data architectures for my company. (the other book was Designing Data-Intensive Archictures by Martin Kleppmann)
Stonebraker et al are very opinionated (especially about SQL and relational databases), but in a way I can accept because a lot of his thinking is based on first-principles. Stonebraker also has a string of database successes (Ingres, Postgres, Vertica etc.) which gives him enough street cred to prove he's not just spewing theory from an ivory tower. He's not necessarily correct in every opinion, but his opinions are interesting and worth considering. I enjoyed his talk on "Why Big Data is at least 4 different problems"
I generally tend to agree that he can be extremely opinionated especially these days. A lot of his opinions being on first-principles helps, though some of those have evolved a bit over the year. The red book in particular I appreciate because it wasn't solely Stonebreaker but rather a collaboration. My understanding is the updated version there was a bit of back and forth on some of those things about re-writing history or being overly opinionated on certain things that were a bit one sided vs. a balanced view. The end result ended up nice and balanced, but it was in large part because it was a work of 3 very knowledgable people in the space.
Added to that he runs commercial companies and continues to do so based on database technologies. I'd rather take an opinionated answer from someone of his caliber (Turing award + running successful commercial companies based on the same tech).
I worked on the memory allocator for a feature called Flex Tables - https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/Fl... which involved loading unstructured data into the column store database. I worked with two incredible engineers (who I believe were sniped by Facebook later). One was a distributed systems expert who spent the entire summer on and off debugging a multi-server crash where the root cause and failure occurred 30 minutes apart. When he finally crushed it I went outside for lunch that day and he was sitting in a lawn chair on this corporate office drinking a beer and staring in to the distance. I had this feeling that he was untouchable and alone in the universe that day, having conquered a mountain few people will ever climb.
The second guy more or less taught me how to use Vim. And not just use it, but move buffers around and navigate the filesystem so fast that it seemed he was wired directly into the computer. Up to that point I had not worked with a very very experienced programmer who was still practicing. He would write very complex regexes directly in the vim prompt to find the right parts of log files.
The overall team had been acquired by HP 18 months before I arrived and you could tell that people were beginning to move along. However many of the folks there had worked with Stonebreaker at MIT and then at C store. There was a feeling that they all knew things about column store databases that were not widely known. In particular the engineering manager once walked us through the very first project he implemented at Vertica, which was backup and restore. He more or less derived the whole system from a few principles of when data should be saved over the course of 2 hours.
It was an extremely technical place to work with data sizes and problems I had never encountered. It gave me a sense of the the sheer scale that some companies operated at and what was possible by starting with C++ and building the system out bit by bit over years. Many of the approaches there actually mirrored architecture work I did later on a multi-camera tracking system.
I was fortunate enough to be in Stonebraker's undergrad database class. He had the laid back teaching style that made complex things seem easy. I was like this relational stuff was not that hard. What I learnt in that class are still relevant to current day.
Much of the chapter on where we failed is about problems in the academic system itself. He has some proposed solutions, but I don't know how effective (or realistic) they are. I also don't have easily expressible solutions myself.