Turing Award Winner: Postgres, Disagreeing with Google, Future Problems | Mike Stonebraker

0:00Mike Stonebraker:Computer science may well not be a growth industry going forward. This is Mike Stonebraker. He's a Turing Award winner, famous for his fundamental contributions to database systems like creating Postgres and more. What was the hardest part of that implementation? A query optimizer. It's just algorithmically difficult. How do you identify the people who aren't smart? Well, I mean, it's very easy. He shared interesting technical takes from his experience. On our benchmarks, large language models get 0%. Why did you disagree so much with MapReduce? That wasn't the only thing Google was stupid about.

0:38I'm curious your thoughts on unsolved problems in databases and what you think the future might look like. Here's the full episode.

0:52the first thing i want to go over is the story of how postgres got started but for that i kind of want to start the beginning how did you get into building database systems when i graduated

1:04Mike Stonebraker:i had the good fortune of being hired at berkeley and i it was clear i had to you know continuing what I did for my PhD was not going to go anywhere. Then, as well as today, you're way ahead if you get adopted by a mentor who knows the ropes. So Gene Wong, who is still alive and still kicking, took me under his wing and said, well, let's do something together. And this was 1971, which was the year after Ted Codd wrote his pioneering paper in CACM. Gene Wong said, well, let's take a look at database stuff. And at the time, the competitors were a thing called the CODISIL proposal, which you're probably too young to have ever heard of.

2:05Mike Stonebraker:And so it was a low-level spaghetti network proposal where you executed queries by following pointers. And then the alternative was the IBM proposal, which was a thing called IMS, which is still available. And it's hierarchical data. It's a tree. You organized your data as trees. And even at the time, IBM realized that trees were not general enough to solve many people's problems. So they hacked on a way to make it a limited network structure. So it was clear that was a horrible hack. The CODISIL proposal had all kinds of bad properties besides being low level and really hard to debug. It also had the property that if anything changed in what's now called your schema, You basically had to throw away everything and do it all again because it was absolutely rooted at the physical level.

3:18Mike Stonebraker:Whereas Ted Codd's stuff made perfect sense. And so Gene said, well, let's build one of these puppies. That's clearly the next thing to try. So he started building Ingress in 1972. I was an assistant professor at Berkeley. As you know, if you're an assistant professor, you have to – you have about – you get five years to prove that you're a big shit. And they fire you or they give you tenure. So Ingress was my ticket to getting tenure, which happened in 1976. That was where it started. And then again, you know, happenstance. at the time, a lot of people would build prototypes, which were sort of student-y like code, which means you could get it to run, but if you gave it to anybody else, they couldn't.

4:15Mike Stonebraker:So we put in the first 90 % to get something we could run. And then for whatever reason, and we put in the next 90 % to get it to where it really worked. So the University of California version of Ingress really worked. And so over the next couple years, about 100 universities started running it because Unix became the big thing. And so this was a free database system that ran on Unix. And so it was quite popular in the academic world. And so we started getting lots of visitors at Berkeley who would say, gee, this is really nifty-looking stuff. What's the biggest ingrist application you have? And we'd be forced to say not very big.

5:15Mike Stonebraker:And so this was brought home in spades when Arizona State University considered running Ingress on their student records data, all 40 ,000 students worth. And they could get over that they had to get an unsupported operating system from Bell Labs. They could also get over they had to run an unsupported database system from these guys at Berkeley. But the project went down in flames when they realized there was no COBOL available for Unix, and they were a COBOL shop. So unsupported operating system, unsupported database system, no COBOL, doomed us to, you know, irrelevance. And it was clear the only way out of that was to start a company.

6:12Mike Stonebraker:And so in 1980, we got venture capital as it existed then and started Ingress Corporation to move Ingress to DexVMS, you know, a real operating system. and we had a real company that would support Ingress. And that was the start of the commercial journey. I saw that Ingress was competing with Larry Ellison's offering at Oracle. Yes. I saw that Ingress was certainly better than what they were offering, but they were still competing somehow. How did they compete? Larry Ellison is a fabulous salesman. And at the time, he made present tense and future tense indistinguishable. And so he basically lied to customers.

7:16He would ship stuff that didn't work and have his initial customers help him debug it.

7:25Mike Stonebraker:So I think he engaged in what I consider very shady business practices. But lying to customers, I think, is unconscionable. So, for instance, there was a thing called referential integrity, which is if you fire an employee and he's the last person in a given department, do you want to delete the department or do you want to have it be a department, a ghost department? It's all that kind of stuff. And so Ingress Corporation implemented referential integrity. Oracle Corporation wrote two manual pages that said, here's the definition of referential integrity, which everybody agreed to. And then down at the bottom, it said, not yet implemented.

8:25Interesting. Yeah, I had interviewed someone who worked at Sun Microsystems, and they had a similar opinion that Larry Ellison was a little bit shady. So it seems to be a commonality. I also saw somewhere else in something that you had said was that when Oracle acquired MySQL, that everyone kind of got afraid of that and moved to Postgres.

8:54Mike Stonebraker:That was the genesis of Postgres replacing MySQL as the preferred open source relational database system. So you created Ingress and there was a lot of technical innovations in it so that it was better than the incumbents. But ultimately, it went away and you developed Postgres. What was the thing that Ingress didn't do that Postgres would do? The big thing that guided us at the very beginning was the original reasoning for the academic version of Ingress was we were going to support a geographic information system that the neighboring professor Praveen Varaya wanted. And so to support a GIS system, you need points, lines, polygons, line groups, that sort of stuff.

9:56Mike Stonebraker:And it was clear that Ingress couldn't do it because the data types we put into Ingress were the standard ones, integers, floats, text strings. And you couldn't efficiently support GIS types on top of that. So as a GIS, the academic version of IGRS was a complete failure. And that was in the back of our mind. The other thing that happened, this is a little out of chronological sequence, but it helps make the point, is that the commercial version of Ingress, I think around 1985, you know, there was ANSI had just proposed a date and time standard for relational databases. And so commercial Ingress implemented date and time, using the standard Gregorian calendar.

11:05Mike Stonebraker:And so I was associated with the commercial version of Ingress as well as I was still at the University of California as a professor. So I got a call from an Ingress customer who said, you implemented date and time wrong. And I said, huh? We implemented the Gregorian calendar and you can subtract. And, you know, if it has, you know, days have 30 or 31 months except for February, except for leap years. So subtraction on dates works exactly the way you would expect it to. But he said, that's not what I want. In his particular world, he said he was dealing with bond financial instruments. And for some reason, I mean, you got the same amount of interest on his financial bonds during each month, no matter how long the month was.

12:12Mike Stonebraker:So he had the date you bought the bond, the date you sold the bond, he wanted to do a subtraction, multiply it by the coupon rate, and say that's the interest we paid you. But of course, his version of subtraction was March 15th minus February 15th is 30 days, because that's the definition of his calendar. And so he had to retrieve two dates out to user code, do the subtraction in user code, put the answer back, and it cost him a factor of two or three in efficiency. And he said, why can't I just overload your definition of subtraction with what I want? And, of course, with Ingress, it was hard-coded.

13:02Mike Stonebraker:And the problem was, this is a case where you wanted bond time, just like you wanted points, lines, and polygons. And so Postgres was engineered to have an extendable type system. So you could have whatever data types you wanted. And they were very efficient. And that was the main gist of Postgres, was that it had that flexibility. And as, you know, in business data processing, most people were happy with the standard data types. But relational databases started to spread to all kinds of other places. what are called abstract data types or stored procedures, a bunch of names they're called, had great applicability.

14:00Mike Stonebraker:And so Postgres, that was the big thing in Postgres. Postgres also supported what the AI guys at the time wanted in the way of inheritance. We also supported time travel, but the implementation absolutely sucked, and it got taken out after a while. So there were a huge number of really nifty things in Postgres. You mentioned you want to hire extraordinary software engineers, and I think you've said before that you have no trouble finding those people. How do you identify those people in your hiring, that they're the extraordinary ones? It's usually pretty obvious. I mean, I have a good feel for how difficult stuff is.

14:56Mike Stonebraker:If they get 3x the amount done in school that I think is reasonable, then they're incredible. On the flip side, you had this interesting quote. I wrote it down. You said, I can't stand people who aren't really smart. It's challenging to talk to them. How do you identify the people who aren't smart? Well, I mean, it's very easy. you talk to them and you can rapidly surface whether they're smart or not. What was your master's thesis? What did you do? Well, how did it exactly work? Well, how did you deal with error conditions? How many processes did you have? Why didn't you use threads? I mean, you ask them technical, deep technical questions.

15:53You gave a talk, and I think there's also a paper behind it, of this idea that one size fits all database systems, not optimal. One size actually fits none. And that what you really want is database solutions that target specific needs. What database offerings do you see today that are one size fits all?

16:15Mike Stonebraker:Well, in 2004, when I wrote the paper, we had an academic project which was building what became StreamBase. And so a stream processing engine looks nothing like a relational database. And we had the gist of an idea for column stores for data warehouses, which was popularized by Vertica, looks nothing like a row store. So here were three wildly different implementations that had no resemblance to each other. And in each case, they were an order of magnitude faster than the other guys. So it's pretty clear that with those three instances, you give up an order of magnitude when you're running a database system that isn't architected for your kind of stuff.

17:12Mike Stonebraker:I think that's still true. I mean, I think ClickHouse is a column store. Pinecone is faster than user-defined types on text-based vector processing. And so I think it's still very much the case. And I think there's no difficulty putting a common parser on top of multiple implementations. Postgres has so far chosen not to do that. They don't implement a column store. And so I think they are not competitive, you know, on sizable data warehouses. They also don't have multi-node support, again, for people with big data warehouses. That's table stakes. So I think it's just as true today as it ever was.

18:14I think that what is true is that if you want to get going, you have a database problem.

18:24Mike Stonebraker:You know, the answer is choose Postgres. and there's a huge programming community, all kinds of data type implementations. It's free. And you can find Postgres talent easily and get going. And so I think it's a great choice for lowest common denominator. And until you're trying to do a million transactions a second, it works just fine. Until you're trying to support a petabyte data warehouse, I say at the low end, it's absolutely the right. One size fits all, at the low end, it's Postgres. At the high end, that's just not true. GPUs, do they make available some new opportunities to optimize databases?

19:18Mike Stonebraker:Probably, but I think the big challenge is that GPUs are, you know, SIMD, you know, single instruction multidata. And that's the anathema of indexing. And so whenever indexing is the right answer, they're probably not a good idea. And I think also you've got to architect them so that the bandwidth from storage is not the bottleneck. And so if they're an add-on to the CPU, as often as not, the bus connecting it to the GPU to the CPU is a bottleneck. Can you explain why indexing would be not as effective when there's SIMD? So let's say I'm looking for Ryan's salary and I have a B-tree. So you go to the root of the B-tree.

20:31Mike Stonebraker:You find the divider that has both sides of Ryan. And you follow the pointer. That's a memory access for sure. Then you do it all again. And you do this like three or four times. So that doesn't parallelize well. So the answer is indexing doesn't parallelize well. You mentioned B-trees. When you first implemented that first version of Ingress, did you write all of that by hand? Because I imagine there's probably not some existing B-tree library or something. Yeah, we wrote the original version of Ingress was all written from scratch. What was the hardest part of that implementation? Query optimizer.

21:18And why is that hard?

21:20Mike Stonebraker:It's tough. It's just algorithmically difficult. It's still, if you ask most any senior database programmer what's the hardest part, they'll still say the optimizer. MapReduce came out at some point in the early 2000s, and it kind of took the data world by storm. People were really impressed by it. They thought Google really knows what they're doing. This is the best thing since sliced bread. But it seems like when I look at the literature and what you thought at the time, you can kind of disagreed heavily. Why did you disagree so much with MapReduce? Well, I think there were a lot of not very enlightened people who said, Google is really smart.

22:11Mike Stonebraker:They must know what they're doing. And so we'll do whatever they say. And so they would engage in Hadoop or engage with Hadoop. But Hadoop is ridiculously inefficient. And so at the time, you know, others, you know, Dave DeWitt and others who were involved in our 2011 paper, we understood distributed databases and understood that you could beat the heck out of Hadoop. with a distributed database system, which is basically what that 2011 paper says. And of course, it's true. But that wasn't the only thing Google was stupid about. So Google also had the opinion that eventual consistency was the right way to do concurrency control.

23:16Mike Stonebraker:And so that was postulated from on high by Google all during that same period of time. And it wasn't, and all the database people said, you know, you're out of your frigging mind. Because it doesn't, it solves one particular kind of problem, but only, and that very rarely occurs in practice. Why did they pursue eventual consistency? Okay, well, the idea is that you have an East Coast database and a West Coast database, and they're replicas. So you want them to be the same. If you say, I'm going to do a transaction, I'm going to decrement by one the number of widgets in the West Coast warehouse.

24:03Mike Stonebraker:Then I'm going to, before I commit that transaction, I'm going to update the East Coast warehouse, pay a message over and back to update it. And then to make sure everything goes well, it takes another round trip of message to make sure that both of them actually do the commit correctly. So it's expensive to do a distributed commit. And it still is. And so the idea was, well, you do the West Coast update. You decrease the widgets by one. You just send a message asynchronously and not in a transaction. So that eventually the East Coast warehouse gets decremented by one. So meanwhile, if you're on the East Coast, you decrement, you know, foodstuffs by one, you send an asynchronous message.

25:01Mike Stonebraker:Eventually the West Coast gets it and eventually everything settles out. So if you're allowed to go below zero, then what will happen is if the East Coast guy and the West Coast guy simultaneously sell the last widget, then eventually the state of the warehouse will be minus one and somebody won't get their widget. it. And so if you're allowed, like Amazon, to say usually ships in 24 hours, then maybe you're allowed to oversell. But most enterprises can't do that. And so eventual consistency just doesn't work. So we talked a million hours ago about referential integrity. So referential integrity in a sales system is integrity constraint is stock is greater than minus one.

26:10Mike Stonebraker:And that fails with eventual consistency. And so Jeff Dean of Google finally figured that out. And when they did Spanner, Spanner had a conventional transactional system. And so Google completely abandoned eventual consistency and completely abandoned MapReduce. So the tradeoff's basically correctness for performance. So it's performance versus data integrity. And if you don't care about your data, then you're willing to deal with bad things happening. So did you ever talk to the Google team while they were doing those things that you thought were so wrong? We talked to them before the 2011 paper and said, why don't we partner up and do some stuff?

27:14Mike Stonebraker:And they weren't interested. So they declined. Have you seen other examples in other big tech companies where their databases or database solutions where you actively disagree with them, like maybe Amazon or Facebook? Well, I gave a talk at Amazon maybe three years ago, and I told them all the things I thought they were doing wrong. And I think Amazon's problem is that they are supporting, you know, 15 different database systems. And that's about 12 too many. So I think they have their own culture. And I said, you're supporting too many database systems. And at this point, they haven't chosen to retire any of them.

28:09Mike Stonebraker:Why do you say that the 15 should be three? Well, they're supporting a graph-based database system. And it's well understood that a graph-based database system is almost never the performant option. And so if you want a graph, if you like the idea of having a user interface that deals with nodes and edges, is that's fine, put a layer on top of a relational database system that gives you that user model. And so most of their database systems, there's some other of their database systems that's better at what it does than it is. And so the answer is you should retire you should retire any database system that isn't performant in a big enough market to justify the maintenance.

29:14You've influenced industry significantly from academia. And my one thought that I had is why not work directly in industry? Or why do you prefer the position of being in academia and having influence in the way that you have versus just taking a job at AWS or something like that, being a very distinguished engineer there?

29:42Mike Stonebraker:Because that gives you a boss. And that gives you company rules, limits your ability to publish, limits your ability to go talk at conferences, limits your ability to go poke at what various competitors are doing that they won't tell their competitors. But mostly, I really like being in startups. And after the commercial version of Postgres got acquired by Informix. You know, I was working part-time for Informix, which was a 2 ,000-person company, and I didn't feel like I could make a difference because it was bureaucratic and and whatever the president wanted, he got. So I think I'm just not cut out for, I'm not cut out for politicking.

30:43Mike Stonebraker:I don't do that very well. And I have a hard time interacting with people I think are dumb. And that, again, so I guess I have some problems with big companies. I want to talk a little bit about DBOS. I just thought it was a really interesting technical model. Can you explain what DBOS is? We started the academic project in

31:14Mike Stonebraker:2019, 2020, something like that. And the gist of it was, at that point, Matei Zaharia, who was on the faculty at Stanford, was also one of the founders of Databricks was the original creator of Spark. And so he said at the time, Databricks, you know, basically was running people's Spark jobs on the cloud. And so he said at any given time, we might be orchestrating a million Spark jobs. And so we have to write a scheduler that's going to decide who to run next at scale a million. And he said there was no, we tried all the schedulers written by the OS folks, and they couldn't, they didn't scale.

32:14Mike Stonebraker:So we put all the scheduling data in a Postgres database, and basically a Postgres application was doing scheduling. And then it sort of clicked that, by and large, most everything you do in an operating system is managing data at scale. And you should do that using database technology. So why don't we just replace at least the upper half of Linux with a database system? So that was the gist of the academic project. and we worked on it at Berkeley and Stanford in the early 20s. And it was very successful. It clearly worked. And in the process, the Stanford folks wrote an extension to JavaScript so that you could program.