 Alright, so our next panel is to discuss things that happened after Postgres, or sorry, after Ingress, which includes Postgres and other projects going on at Berkeley at the time. Our moderator is Joe Hellerstein, and we have an amazing panel which includes Marco Seltzer. Oh, sorry, sorry, please. So, there's a little serendipity going on here on the screen. I didn't prepare very much, which I think I took, I learned that from Mike, maybe. But I showed up and we're just going to try to be as smart as we can, which I can't compete with Mike on, but we'll do our best. And so, I didn't have any slides or anything, and it was Marco said to me, just now why don't you get a picture of the Triple Rock, because that's where all the research on the Postgres project happened. So, I went to a large internet search engine, and I did an image search for the Triple Rock Brewery, and I threw it on the screen, and I was just assaulted by Mike and Teresa Olson, who said, that's us! And they claim they weren't there very often, but this is a random photo from the internet. So, there's at least two members of the research project there. I guess that's Mike in the blue shirt, and next to him is Mark Sullivan, who literally wrote his PhD thesis at the Triple Rock in The Beard and actually The Hair, who knows if it's still there, but it is quite amazing. So, I will introduce the panel, and then we can go around, we can reminisce a little more. On the far end here, a fellow named Mike Olson. We have Margo Seltzer, Wei Hong, and Anand Jingren. Excellent. I showed up at Berkeley actually kind of midstream on the Postgres project in 1992, 1991. So, these guys are sort of my elder brothers and sisters on the project, and so a lot of what you're going to hear is from them, although I was definitely there for some fun, fun times. As we said from the first panel, which I didn't know much of that history, I've always wanted to know more, this was where Mike closed the loop, right, because he'd done Ingress, he'd done RTI, and then he was taking everything he learned as an entrepreneur and an industrialist back to campus to do research again. And that virtuous cycle has defined the rest of his career. So, I guess maybe we'll start the panel on that note and just ask you guys, your recollections of maybe first meeting Mike as a noted figure in the industry as well as a famous professor. Can I start with that one? So, it turns out I actually met Mike before I got to Berkeley, but I didn't kind of exactly know that. So, I worked at a hardware startup before I went to grad school, and we were an early adopter of this funky relational database system called Ingress from RTI. So, I actually got to see the videos of Jerry and Mike talking about Ingress and things like that. It was really special, but I was like a really dumb baby programmer fresh out of college, and my somewhat sneaky boss, I think, said, can you do some benchmarks? Because I don't think we're getting the same numbers out of the software that the RTI guys are telling us. So, I like, you know, they said they were doing N transactions per second, and I very diligently looked up what a transaction was, and, you know, did a TP1, you know, read out if I write transaction, and got like horrific performance, or, okay, what would Mike call this performance? This is a quiz. Pig dog slow. Does that sound familiar to anyone? Okay, that's one of my favorite technical terms that I learned from Mike that I've shared with all my students when things don't run well. They're called pig dog slow. So, I showed my boss these pig dog slow numbers, and they were not happy. So, they invited this guy from RTI who was going to come talk to us. This guy was my stone breaker. I was a dumb baby programmer. I had no idea. So, I like, you know, walking with my numbers that are in order of magnitude slower, and Mike just looks at me and goes, oh, yeah, we're not quoting transactions, we're quoting reads. Okay, thanks. So, fast forward four years, and I'm applying to grad schools, and I then become like a hardware person. So, Patterson and Kat had admitted me to Berkeley, and I'm going to go visit, and Sheila Humphries says, oh, I see you've done some database stuff. Would you like to meet with Mike Stonebreaker? I'm like, oh, okay, sure. And so, I show up, and Mike actually remembers this story, but I don't, which is a little awkward. And then Mike says, you know, so do you want an RA? And I knew absolutely nothing about graduate school. I really didn't know much about databases, but I knew that an RA was a good thing. And so, I said yes. And that, in fact, established my career because I got to work with Mike in grad school. So, that was sort of the connection between those Ingress days and this Post-Gress era. I am equally accidental. So, in the very late 70s, early 80s, I was an undergraduate Berkeley working for Bob Fabry and Bill Joy on the Berkeley Unix project. In about 82, I dropped out for a few years. I traveled through Europe. I majored in Amsterdam. I actually got a post doc in that topic. I came back to the States in 86. I went to work for Eric Almond. Eric left. Eric Almond was at Brittany Lee. He got me a job there. And Paula Hawthorne, my manager at the time, had worked with Mike when she was in grad school. So, she told me I needed to finish my bachelor's degree. She picked me up by the scruff of my neck, marched me down to Berkeley, and dropped me on Stone Records Doorstep. Mike gave me a job. It was a work-study position as an undergrad. And genuinely, genuinely created the career that I subsequently had. So, had I been thinking ahead, I might not have chosen databases. As it turned out, it's been absolutely tremendous for me. When I met Mike the first time, the 35, I said, he's a big guy. And, yes, not big in the sense of what we're talking about here, but he's a big guy. And I kind of, for five years, I kept thinking, what should I say about him? So, I said, okay, here's a chance when I was going to actually finish my PhD, he says, and I get a chance to write my acknowledgement. And I said, okay, let me write in the acknowledgement that I always looked up to Mike. But, man, at that time, he still had not given me my PhD, he says. So, right at the last minute, I removed that particular sentence from my class. Now, today, Mike, I'm going to pay you back because I couldn't make fun of you during those five years. So, I came to Berkeley actually to work with Jin Wang to work on databases. But Jin didn't take that many students and I was kind of lonely and I was just fresh from China. And then I learned that, you know, Stonebrook throws to good parties. Wait a minute, I missed these. So, actually, the very first, some of the very first real American party I've been to, I think is at Mike's house in Oakland. I think back then, you know, Nancy was still the baby and so that's kind of why I met Mike, he threw the parties. And then, I think at 89, Jin had to go to Washington. And then I asked Mike, can I join you for real, other than the parties? So, wait a minute, I want to know about these parties that I was never invited to. Did you go to the parties? That's our research venue right there. So, I'll tell you about this one. Mike got a lot of money out of the Digital Equipment Corporation in about 1991 when they were just going south. I don't know how this happened, but we had these stacks of cash from DEC and Mike would show up at the Triple Rock. We'd all been doing research for a couple hours and Mike would come in and he would lay a pile of 20s on the table and he would always say, oh, don't worry about it, it's DEC dollars. And I remember thinking, first of all, it's a good thing he's got money from the Digital Equipment Corporation because otherwise, how would we pay for beer? And then, second of all, I remember thinking, should he really be doing this? And it was only like many years later, I was like, what a nice guy for, you know, making us all feel comfortable that he was buying us beer so we could keep doing research. But yeah, there was a lot of underwriting of the research by the Stonemaker family, I think, is what was going on. So, actually, so the DEC story is kind of funny. So, I moved back to Boston. I have children. I'm standing on the sideline talking to a parent who has a child in my daughter's class and turns out he was a marketing guy at DEC you know, way back and we get talking and it turns out he gave you the money that paid for my PhD. So, we actually didn't get to my question, which is good because now I get to ask it again. So, this could be posed in the form of a question to the Ingress folks, which is, before he started Ingress, what did he say other than, well, people who do it for dollars wouldn't do it that way? Yeah, why? Was there a line? Like, I think maybe people would do this for dollars. One of my reactions when I first met Mike and he was teaching the database class and I have the notes of this was the pride he took in both his students and in his impact on the industry. And this was informing for sure the way that he was doing research and business. But what I have in my pencil notes is the family trees of the database industry and which of them came from Ingress and which of them came from System R. And I at some point had to teach this class when Mike helped me get a job at Berkeley and I thought, could I deliver that lecture? I said, no way could I deliver that lecture, but what great stuff. So, just curious, you know, a bunch of you, one, two, three, four, all of you five have followed in Mike's footsteps and done both research and built companies and been involved with major companies as well as startups. Like everybody here has been involved in startups as well as big companies in some way. So, do you guys reflect a little bit on how you think about how Mike was an impact on those sides of your career? Oh, sure, I'll start again. All of this. So actually, I think there are a couple things. So I just want to say that, you know, one of Mike's great strengths, he's not very strongly opinionated, we know, but every once in a while when he does in fact issue an opinion, he actually is willing to change his mind and I felt very fortunate to get to experience that. So back in the early days of Sleepy Cat, this was sort of in the dot-com boom, Mike gave me the sage advice, you guys are morons. You know, you need to be taking venture and grow big and yada, yada, yada. And we, you know, like I did all my advisor, advisorial advice, I ignored it. And then a few years later I ran into Mike and by this time the dot-com boom had sort of tanked and Mike said, you know, you guys were really smart. And I was always really baffled because I'm not quite sure that our cleverness had really changed a lot in that interval, but I was really glad to see that Mike was able to change his mind. But I think the model of picking the right license for software so that you can enable not only you to go start things, but other people to actually pick up software and do cool stuff with it so that, you know, if not invented by the ingress and the post-crestes of the world, it was certainly pioneered and demonstrated by it and it certainly did well by us. I will build on that message. So I was in grad school after a Ph.D. Mike hired the entire research team out of Berkeley to start what was then Miro and later after several lawsuits named Alastra. I hung around, Stonebreaker told me that I was going to be a world-class college professor and because every role model I had, numbered one, was a college professor. That seemed like a good idea. I discovered in that one year after Hong left, after Merle left, I actually didn't like research at all. I just liked those guys. So I dropped out for the last time. I joined Alastra. I got into Berkeley by way of a bunch of Stonebreaker alumni. I joined a bunch of Stonebreaker alumni. Margo and I worked on Berkeley DB which led to Sleepy Cat. So my start-up career was largely shaped by my experience and the people. And I'll come back to this. I think we had just like the English Project, a special group at a special time in a special place. And that really defined the post-gross era for me. But building out what Margo said, so I decided I was going to after I sold Sleepy Cat, after we sold Sleepy Cat to Oracle and then I left Oracle after a couple years. And I got really excited about this Hadoop software. And as Dave DeWitt mentioned, Stonebreaker and DeWitt were on record. So I thought I better call up Mike and just tell him I was going to do this thing. And you know, Mike was very generous with his advice. Mike, Hadoop's a piece of shit. So I knew I was on to something, brother. So Mike said, hey, Anantya, you can do some work. It's okay, man. But you can't write shit. So how you actually describe your work is really, really important. His other expression was five meters of five yards outside the Berkeley campus or something like that. It really matters. So Mike took it upon himself for every paper of mine to reading it. And my PhD was basically reading three times. And I know the fourth time I read it, if I did a Diff3 against the first one, it would be very, very similar. But by the time Mike had forgotten all the changes that he had done. But one of Mike's things that he said very early on was you've got to put two spaces after a stop. Here I am with a wonderful Lambda calculus result. And all he points out is put two spaces. So Mike, wrote an article in Slate magazine which said that two spaces after stop is the wrong way of doing it. I now know I was right, Mike. So anyway, Mike has taught me how to actually really express, be forceful, be strong. It doesn't matter whether you're right or wrong. It only matters how you come across. And that's what really matters in real life, man. That's what really matters. So I might be the person here who worked with Mike directly for the longest time. I started working with Mike in 1889 and did post-quest and I did illustrator in FormX and then called HERA. So I think it's like 11 years. I don't know how many people have worked with Mike directly for that long. Certainly have, you know, Mike certainly made an enormous impact in my life. You know, my career choice I think when I was a graduate in 1892, that was kind of the wrong year to graduate if you want an academic job because Margot took all the jobs. How many did she take? She was in five places at the same time. Pretty much. Yeah. So, um, but I had some academic, you know, opportunities and I have, you know, offers from the so-called elephants. I have startups and so I asked Mike, you know, what should I do? Right? And Mike in his typical kind of long way and he told me, Wei, you are no Mike Harry. Ha ha ha ha. Ha ha ha ha. Ha ha ha ha. And, you know, and of course, you know, over the years I have learned so much from Mike, you know, the real world problems and what people want in sort of people who do it for dollars. Um, and, uh, so every, you know, then I joined the illustrator and, uh, ever since that, you know, I've been doing startups and sort of transferring technology to elephants and, you know, loving it to this day. So I just want to follow up on, you know, Wei's, you know, eloquent exposition of the supportive nature that one got from an advisor who was, so when I showed Mike the list of schools I wanted to apply to for faculty positions, um, the answer was the expected number of offers there is zero. Ha ha ha ha. Okay. So I'll tell you another blunt thing. So of course I joined Berkeley 85. It was about 20 years too late. So in that first one year at Berkeley I tried to make up for the 20 years that I wasn't. When I was doing an Amsterdam, I was doing at Berkeley. And, uh, so after in 86 I went to Mike and said I want to do Ph.D. Mike said, you are not Ph.D. material. Ha ha ha ha. And he was right. I might have been Ph.D. material but I was not expressing Ph.D. material at that point in time. So I took it upon myself to kind of correct that the, the best day at Berkeley for me was when Mike took his hand out and said Anand it would be a pleasure to have you as, uh, his Ph.D. student. Thank you Mike for setting me right and then for guiding me for the next few years after that. Thank you very much. So, uh, while we're getting on personal um, uh, I after college went to IBM Research so I was sitting with all the, uh, at that time starburst people thinking about grad school. It was a pre-doc which was the school program they had where they made you promise to go to graduate school to get a job at IBM. We don't do that anymore. Um, and, uh, I got accepted to, uh, Wisconsin and Berkeley and I'm a native Madisonian and had a very, very, very hard time deciding where to go. Uh, so I went up to Sprawl Plaza and flipped a coin on the Berkeley campus and it came up Wisconsin and I went to Berkeley so I worked for Mike. Well, so here's the thing. So I worked for Mike and the thing that had happened, I think in retrospect, uh, it was a very considered, uh, decision on my part. I'd been in Northern California for about 18 months so there's now the middle of my first year of graduate school and no girlfriend had emerged. This is, in retrospect, what was going on in my mind and so I went to my thesis advisor and said I'm at the wrong school and I think I should have gone to Wisconsin and I'm going to transfer. And my dad, who's an academic, told me that it was suicide. Because his advisor would have cut him off from all of academic everything forever. And Mike said that's fine, Wendy, you need a recommendation letter. Uh, and I did indeed transfer to Wisconsin where I discovered that what I really wanted to work on was Postgres. And so perhaps to the chagrin of the folks in Madison, I did essentially my PhD work in Montage and Postgres with Mike, with the help of the folks at Wisconsin. And I had the you know, the luxury and the privilege of getting the best of both. But um, it is very It's a flight so you can get a faculty position in Berkeley. Well, you know, there's that too. So then I was graduating and I was getting, uh, uh, also advice about how to get on the job market. I wanted to be an academic and uh, you know, my option was limited to and Mike encouraged me to apply to Berkeley and I'm sure was involved in some kind of conversation back there about getting me a position there. So um, it is unusual for a strong minded opinionated field leader in academia to also be so supportive of his people. I think I've heard this from just everybody that's worked with Mike over the years. The guy will take care of you and make sure that his folks do well and it's been, it's been huge for me. So I would like to thank you as well. This is, this is getting gooey. So, um, let's, uh, we should talk about technology and research. Really? So I would submit in all academic honesty that Postgres was the most audacious system conceptually ever designed and that poor Mike has been in reaction to this for years saying one size does not fit all because he jammed like seven startup companies into one research project which seems like a shame when you think about monetizing it. So, but, you know, I made a list, but I'm going to see if this team can put together a list of all the startup companies and PhD theses and what would have been probably major research projects at other universities that coexisted inside of Postgres. So we're going to go to the board. Alright, this is an exercise. You guys are back in school. We'll go to the board. We're right now. He's his topic slash startup companies invited in Postgres. Please. Any of you? Complex updates to the same as JSON and they're both the same as all of the most equal leaders. Okay? That's a lot from our parents. I like how you don't reach it all every minute. We'll leave that as an exercise to the student to figure out the mapping. I like that one. I like that one. Sleavy Cab was a director's role. Sleavy Cab was a director's role, and mine is I had to write a Beatry one last time in my life. An extensible person. I want no overwrite storage systems and every storage system today used on Flash and pretty much everywhere else. I think that, you know, Professor Selzer is saying even more than one thing at a time. I'm going to break that into two. She's a little smarter than the average bear. Good thing we're here, huh, Joe? No. Have you been in a class with a professor recently? No. No overwrite storage. So imagine a database system, if you will, that saves data forever, never throws it away and lets you ask queries at points of time in the past. This still does not really exist, but lots of people are talking about it. And of course it makes perfect sense today. There you go. Okay, it's finally come to fruition. And actually, Mike, you'd be proud to know that I have a master's student who just wrote a thesis on sort of temporal databases and being able to figure it out. Keepin' that tradition alive. Okay. And then the second one you said, Margot, number four here, we'll say is how about Flash-based transaction processing? Oh yeah, that was exactly what I said. That's what you said. You did? So I actually said three things. I said three things at once. Temporal database systems as opposed to theories. All right. I heard someone who's not on the panel, but maybe should be. Marty Hurst, Professor Marty Hurst, who was there at the time. Six. We'll call it, should we call it complex event processing? Yes. Complex event processing. Joe writes that, I have to tell you guys. So when I got to Berkeley, this is a true story. Postgres was written in Lisp. No lie. The original Postgres was written in Lisp and I showed up just as Simeron Taylor and Paul Aoki had finished a major project to create the C pre-processing macros to turn Lisp into C. We spent three years car-cutter-cattering our way around that damn database system. That's true. That's true. You want to talk complex events, brother? Yeah. So another topic, Mike, I would like to add to your list for this afternoon is what were you thinking? Yeah. It's well known today as a systems language though. No, actually on that measure, I think Postgres was the first database system that did MapReduce. Yeah, good. Yes. Number seven, code next to data, right? I have to add that the hardest part of MapReduce in that, of course, is the query optimization challenge involved in dealing with all this complex code embedded in your relational queries. So that was my PhD thesis. That MapReduce guys have done this at some point. I'm waiting for the consultant call. So something which is not obvious was simplifying the server-side process. Right? So doing single-threading on the server-side. And now we all clap and say Node.js is so amazing because it has a single-threaded model. So this is interesting. So Mike and I wrote this paper like about seven, no, maybe ten years ago now on the architecture of a database. I modeled it on the class I took from him. I drafted it and then Mike edited it. We spent the first ten pages on process models for database systems. I don't know if you remember this, but we sent it to Jim Gray. Jim said, this paper is horrible and there's all this nonsense at the front that nobody cares about. Which was, I was floored. I was floored and we sent it to many other people who thought that was a big contribution. But it was fun to watch those guys debate that over email. Process models? No, there should be no process models. What are you saying? What I'll say is that it's a really important aspect of building a real system. Right? Alright, we're missing geospatial. Yeah? What else? Multilevel storage? Do you remember it was a optical disc? Optical discs and stuff? That was me right there. There you go. So, honest to God, all of you who started companies with Mike, this only turned into one. What a loss, right? But seriously, totally audacious effort. Totally audacious effort. So I'm not aware of anything that's been done since that did this many things at once and it kind of worked. Really, really incredible. And of course, the impact of the system, and I do want to spend some time on Postgres because that was our job, impact of the system has been enormous. I mean, I can give a speech about that, but actually, do you guys have the way you were intimately involved in the commercialization of Postgres and then in subsequent efforts? So please. So one story I would take, I'll talk about in Postgres, was community. So I think back in the Postgres days, we had hundreds of users around the world. I think back then, we had people as far as Russia in the late 80s using the system, doing something. And I think one of the famous users was so-called the Tomahawk lady. She's doing something with the rule system. I have something to do with Tomahawk missiles, which was actually really scary because if you have read the Postgres rule system paper, there are multiple rule systems. And each one of them have some form of non-deterministic semantics. I wrote one of those papers. So that was kind of a scary application. So because of the focus on real world problems and it was just natural to kind of go into this illustrious world. When we started illustrious world, it had a lot of use cases, and it was kind of easy to pitch to the VCs. So that was kind of an easy transition into the commercial world. One of the use cases for this. So we had a forum that you could just log into and post questions and bugs if you're using the software. And lots of traffic on that. The Tomahawk missile lady, I remember. The other one was, hello, is Ivan from Minsk? So a nuclear mission, a nuclear reactor in Russia was running this software. Like, you know, it's just written by a bunch of graduate students. Hey, I had when I left the cozy environment of IBM two years back I needed a database system. So either I paid IBM money for the database that I really liked or I paid no money for the database that I really liked. And Postgres has been just immensely, immensely stellar for the use cases that I've been doing. And it's so good, even though I didn't write a line of quotes, so that way I was like Mike Stonebreaker. Mike actually kept me away from okay, just go do whatever you want to do. Don't touch Olsen and everybody else. I can recognize, oh yeah, I actually did contribute something out there. It's been, it is just a fantastic database. And by far, forget my SQL, forget anything else. And by far, the best open source database that exists. There was a panel at SIGMOD in Madison, so this must be 2002, about with the Postgres open source guys who are not us, essentially. They weren't Stonebreaker people and how they sort of had the courage to pick up this research project and turn it into, you know, well, a 1990s era and now 21st century open source and Mike was so gracious at that panel, I remember, because what he said essentially was, well, you know, we don't have that much to do with Postgres SQL and I remember thinking at the time that, you know, the idea that the guy with all the technology ideas behind the software was kind of making room for the open source community to take ownership of the project is just, you know, set in my mind, that's the way you build open source communities. You give people room to succeed. Now, Postgres, because it is so good because it is open source, is pretty much the de facto way to start a database company. So, I have another list of commercial software that's been built out of Postgres. It's kind of scary and this is just off the top of my head. So, anybody want to, I got a list, but anybody want to shout out some names? Say again. Matiza. Yup. AsterData. Green Plum. Enterprise. EnterpriseDB. Which didn't sell for as much as the rest of this stuff, but that's okay. There's more. Hadapt. There's more. No. No. Very good stuff. It's a different area. I think Illustra, too. Illustra? Thank you. That would be Maro. There's actually maybe the biggest deployment of all is the one that's missing. Yes, let's hold that thought. The biggest deployment of a Postgres-based system is Redshift. Amazon Redshift. Parxel was a Postgres. Yeah. That's outrageous. There's a lot of value embedded in that stuff. That's just pretty incredible. So with that, let's tell a little bit of a story about the early days of Maro Systems. I guess I was there from the beginning. So I think what we wanted was a starting name following the Ingress theme. We wanted to find a painter. So we started with Maro. We bought a lot of art. You bought a lot of Maro paintings that remained in the office for a very long time. So we said, okay, we're going to do a more modern painter. We used, so pick Maro. But of course, there was some German, we got a letter from some German diss manufacturer and said, well, you can't use Maro. We said, well, we're database systems. Well, but you run on disks, so... You can't use it. So I think that's after we bought a lot of paintings and a lot of, you know, mugs and everything made, but you can't use it. So then we picked another one. We hired a firm. The firm came up with Montage because we had this. At the time, I think we wanted to be a multimedia database. You know, sort of the Hollywood was one of the major sort of verticals we were trying to go after. But that was taken. I forgot what the conflict was. So we ended up... We got sued by a bunch of Wall Street types that had some kind of analytic software. That's right. Yeah. So then we ended up with... Fucking bankers. Yeah. So we ended up with the illustra. And I think Mike Austin had a kind of interpretation of that name. I don't even remember that. Mike said, well, it's just a name that is ill, aside from ill, and lust in the middle, and a raw at the end. But, you know, it follows first the stonebreaker philosophy of naming software companies, which is end them in A. Right? Whenever you can go here, illustra, vertical, and you will notice that I work at Cloud Air. All right. We got a little more time. I don't know if you can tell, but we had a lot of fun in grad school. We want to talk maybe a little bit about... We talked a little bit about beer. That was good. Should we tell Mike the story about... Somehow the guy built a really happy bunch of grad students. So I... Correct me if I get the story wrong, but... I don't know about that. We were in an office numbered 60313. And for some reason, because we were, like, really official people, we would answer the phone 60313, because, like, this was in the days... There were youngins in the audience who realized that not everybody had their own phone number. Now you're all old. Okay. So we would answer the phone 60313. And one day somebody answered the phone 60313 and the voice on the other end of the phone goes, Sin City? And from then on, our office was known as Sin City and it was the place to be. So I was in Heaven to Sin City. You were an inhabitant. You were an inhabitant for a while, weren't you? I was next door to a Sin City. And all those people next door, they were really jealous that they weren't part of Sin City. You know, this is a... The fact that actually we had a good time in grad school is despite the fact that the offices that we had been placed were windowless core offices in a 60s brutalist architecture building with sunwork stations or actually then deck stations humming along at, like, 90 degrees. So the fact that we were at the bar was not that surprising. You know, I want to come back to this point, though. It really was, for me, a formative remarkable time. And I mentioned this a little bit ago. Mike somehow gravitationally attracts really interesting people. The group of people that we had working together at that time has remained friends, has been important to me professionally. It was really interesting. Everybody was just a scoot smarter than you were and you worked your ass off to catch up with them. And it was fun, man. It was fun. And I have endeavored in my career sense to create an atmosphere like that. But I think if you look at what Mike did at Ingress, certainly what he did at Postgres, and from what I've heard, what's happened in the groups he's brought together since, it has been the same. And I really do think that the quality of the people in the group are what accomplishes so much. Mike's leadership clearly made a difference, that group of people together, and then to get the hell out of the way is what made a difference. So in the time that remains to us, I think one of the things that happened during Postgres years, which, well maybe actually it happened a little bit on Ingress, but the way Jerry described it, I'm kind of guessing it didn't, is Mike started getting serious about working with science. And the money that came from DEC was actually to do this missions planet Earth stuff. Project Sequoia, which Mike Mr. Olson, you were employed by Project Sequoia, but Mike is still working on this stuff today, both at MIT and in a startup, and it's a big deal, so it's been a big deal for the whole field, but maybe Olson, you can talk a little bit about the early days of that. Yeah, the idea was pretty straightforward. So we're building all these great systems at Berkeley, and it wasn't by the way just Postgres, there was the express, there was the sprite project, and there was lots of interesting work going on. A group of professors including Mike and the Postgres team came together. The mission was, computer science applied to global change. And at that time, evidence had only begun to emerge that the ozone hole above the polar region was a real problem. In fact, the story told at the time by the researchers was, yeah, you know, we've got satellites that are monitoring the size of this hole, but we catch the data, and when it contains obvious errors, so there was evidence of this ozone hole much earlier, but those readings were believed to be an error and were thrown on the ground. In any case, the idea was to bring together these innovative ideas in computer science and to use them in the service of climate modeling and of finding ways of collecting a bunch of remote sensor data, very much kind of the big data applications that we're working on today 20 plus years ago were infomented Berkeley and under the Sequoia project. Yeah. We had lots of meetings with geologists who turned out to drink more beer than database researchers. There was one of those guys, a geologist, I think, down at UCLA, and he was just awful. And I say that, Stonebreaker's here in the room, and this guy was rude, right? So, this thing went on the same. So, this guy went off on, and I don't remember who it was in the room. I'm sorry. The computer scientists got labeled propeller heads, and in retaliation, we called all the earth science guys dirtbags. This guy goes off, and he's screaming at some of I don't know, maybe the undergraduate's working on Postgres, and Jim Gray's in the room, and after this guy vents, there's dead silence in the room, and Gray leans forward and says, well, I guess that's why they call them dirtbags. Yeah. And I'll point out that Mike mostly works with astronomers now to have that right. We sort of switch from, yeah, dirtbags to, I don't know what you call it. So, maybe it's time to switch to the quotable quotes section of this panel. You know, I was thinking. So, we could do another list. We could do another list. So, I started with some. So, I'm going to mention some phrases that maybe some of you have heard, and if you've heard the phrase, you should respond in some appropriate fashion. These are phrases I at least associate with Mike. So, I was disappointed there was not as big a response from Pig Dog Slow as I expected, but how about this one's already come up. Do it for dollars. Anybody heard that one? Have you heard that? Come on. Yeah. Yeah. Okay. How about gluing an orange to a pancake? An apple. It was an apple. You know, I went back and forth, because I think sometimes it was apples, and sometimes it was oranges. Okay, one of my personal favorites now that we know Mike's strong coding background was, well, you can just do that in three lines of code. Oh, yeah. You know, it's awesome. So, I don't know if you have this experience, but people now laugh at me when I say things are really easy to build. I don't know, it comes with age or something. People start to laugh at you. Yeah, and then this one, I remember this one very vividly, because of the person to whom it was directed, and it was anyone with three live brain cells dot, dot, dot. Then there was another description of certain problems that you were discouraged from tackling. Those were called AI complete. Yes, yes. Many of us have been told to go after the high pole in the tent. Avoid hair pie. I can't actually go. And now we open it up to the audience. Do you have any other favorite quotable quotes from the beloved Dr. Stovebreaker? The variation of your three lines of code that I heard countless times was, it's just a small matter of code. It's a simple matter of code. Any others? Can you even eat its own dog? Oh, yes. Something that angered me. You can always tell if Mike was a co-author on a paper, because the occurrence of the word hence in that paper is unbelievable. Can we talk for a moment about boldface? Pardon? Boldface in papers, as opposed to italics. Mike never uses italics. He only uses boldface. He's the only academic who only uses boldface. Any other quotable quotes? $0 billion. We are standing between these good people and lunch at this point. One size fits nothing. One size fits nothing. I've never heard of that. Thank you everybody. We appreciate this opportunity to introduce you to Montage. Montage is the first relational database with full support for objects of any type, as well as SQL3. It's the first database that is truly extensible in a commercial context. It's the first database for decision support for rich data types, the first true database for multimedia, and the best database environment for software re-engineering. To explain to you why your company needs Montage, I'd like to appeal to a 2x2 matrix, which you will see on the screen as I'm talking. Along the horizontal axis are whether you have data that is simple or complex. Along the vertical axis is whether you need to search on that data by running SQL queries or not. This gives us four generic kinds of applications, and I'll just go through them one by one. If you have an application which has simple data and doesn't require any searching, and an example of such an application is a word processing application, then a file system is a perfectly adequate solution to your database needs. On the other hand, if you have a simple application, but require SQL access, and as typified by many business data processing database applications, then the operational system provides you a very good solution to this kind of application. If you have an application that requires no searching on complex data, such as for example electronic CAD, then persistence in a programming language seems to be a good paradigm, and persistence in C++ is offered by many of the object-oriented database companies. On the other hand, if you have an application that requires complex data and searching, and for example complex data would be something like text or audio or video or images or even spatial data, then montage is the solution for you. We're going to have to lunch now. Lunch is just right outside.