The Pragmatic Engineer - Distributed databases with Peter Mattis

0:00He built a gimp image editor while at college, designed the original storage system behind Gmail, and built many more large complex and widely used systems. This is Peter Mattis, co-founder and CTO of Cockroach Labs. Before we sat down to talk, Peter told me, Today we cover why B-trees are so important when building databases and why Peter kept reaching for the data structure over and over throughout his career. How he wrote 100,000 lines of production code per year pre-AI, stop coding between 2022 and 2024 and why he is back now.

0:40why he thinks AI agents are lazy about testing, and how this is an easier fix than it looks. And many more. If you're interested in distributed databases, distributed storage systems, or knowing how Peter manages to use AI to produce unusually high quality and production ready code, this episode is for you. This episode is presented by TurboPuffer.

0:58are ridiculously scalable fast and cheap hybrid search engine built on top of object storage by an engineering team I've really gone to like after spending time with them. The Turbo Buffer engineering team is doing something really really cool. They're completely redesigning their storage architecture from first principles to make storage faster, cheaper and more reliable at scale. If you follow Turbo Buffer, you know that their storage architecture was a massive part of their early success. Redesigning a winning architecture, is a big deal. It's one thing for your query plan to pass unit tests. It's another to bring each query plan to performance parity or better while maintaining correctness and reliability in production. Here's the cool part. TurboPuffer is documenting the whole thing. Their new storage architecture, which they are calling TPUF V3, demands some hardcore systems engineering and they're building it in public, sharing design decisions and benchmark results as they ship.

1:47They're keeping a work log up their journey, and the first post just dropped today. Follow along at TurboBuffer.com slash V3. That is TurboBuffer.com slash V3. Peter, welcome to the podcast. Oh, I'm happy to be here. This is awesome. I wanted to get into, how did you get into tech originally? When did you figure out computers are interesting? I figured that out in elementary school, high school. Gaming was a little bit of a gateway drug for me as a software engineer, as many other people. I remember early on, my mom.

2:17did programming at IBM at some point. I'm not even quite sure what she did, but we had computers always around our house, like Apple II Plus, Apple IIGS. I'm from that era on up. And you know, go to the bookstore, I'd find a book on basic or magazine type in programs. No idea what it was doing, but you know, just kind of like, I was addicted to like, you can produce, put stuff into these computers and you get interesting stuff out. And then I got to college and I was like, I didn't think there was any money in computers. I didn't know anything about it. I started as a mechanical engineer.

2:44Following the footsteps of my dad mechanical engineering as your socialization is my major. Yeah, I got in there and I was like doing like I done some computer stuff before is real foolish move to do this but For a semester of doing these homework assignments and mechanical engineering if they were god-awful like six pages for a single problem And I happened to take a CS course at the same time and it was so easy and then we almost was failing it I'm like, I'm in the wrong. I'm in the wrong field. Let me switch And then you switched? No, I switched, yeah. What was the first software that you built, either a college, it must have been a college, that you were like, all right, this is a piece of software that I'm kind of proud of. That's a complete piece of software. Well, I mean, the big thing that I did along with my remaining college, we had this course, was it a compilers course? I'm not quite sure anymore. This is like 30 years ago, and we were kind of bored with it.

3:32So we want to do something like kind of fun on the side. And I'd done journalism in high school in my senior and senior year. I knew stuff about kind of computer graphics and want to do something like Adobe Photoshop. So I started just kicking the tires and we built up this program that a lot of people know of called the GIMP. And along with the GIMP, I did a lot of the graphics library GTK. This has since evolved just massively since then. It's kind of interesting because after college, I kind of stepped away from it. Didn't really stay involved much past my first year out of college, but.

4:01Definitely people still know me and it led to other some interesting events in my career. And it was like starting Gimp. It was literally just you saying, all right, I wanted to do something like Photoshop. How hard could it be? And then you just, this wasn't through what you learned in college, right? This was like you figuring out how to build, you know, like a graphical, I guess, engine rendering, drawing data structures, all of that stuff. All that stuff figured it all out. I remember trying to look at some papers back then. My roommate was looking at papers. We're just fingering it all out.

4:31And it's one of these things you almost kind of need to be a little bit naive to start anything like that. Except if you know how hard it's going to be, you would never start it. So I think there's like, you have to have this level of like, if you're really truly wise about the effort, you're like, you never get into it. But then when you get going, it just keeps on snowballing. It gets farther and further along. And then at some point you're like, wow, this is really awesome. But there's an interesting little tidbit associated with our work on the GEMP, which is kind of a little bit known. I think we've talked about this before, but it's just kind of fascinating where we were.

4:59getting to the point where we're like, we should release this to the public. And back then there was a Usenet news groups where people would post stuff and there's one on graphics. And remember like just a couple of weeks before we were going to release our first version of the GIMP, someone else came on there like, I've been working on this graphics program and it did everything the GIMP did, every last thing, and then some and we're just like, well, that sucks. I guess we'll just keep on working on it's been fun. And then we release the GIMP, never heard from this other guy again.

5:27And I just took a little lesson from that. There's always going to be someone else working on your idea. You can't get dissuaded if they pre-announce it. Nothing ever comes of it. And a lot of marketing behind some of that stuff that you might hear is like, I mean, I don't know if we stole his thunder. I'm not even sure what happened. You never trace down what happened, but there's a real lesson there. So there's a...

5:47possible future where you read this announcement from someone saying, I'm going to build all of this thing and you go like, ah, you know, someone did it and you kind of go back and just do something else and the game never happens. That's right. Wow. Yeah. I guess especially with today with startups, sounds like just do your thing.

6:03Put it out there, at the very least, right? The advice I give people is like, you might have a unique idea, but most likely there's like a dozen people out in the world who've had the same idea. And there might be a couple of them working on it, but a lot of people don't even work on it. There is like whatever they can't get going on their idea. So, you know, I wouldn't be concerned at all if like you hear someone else working on your same idea. That's probably the case. You know, we're working on some cool stuff now at my current company. I guarantee you there's other competitors out there working on the same thing. And just know it's like it's a competition. You got to enjoy that aspect of it, not be afraid of it.

6:32And what were some fun things that the game pled to? Well, you know, I got kind of tired with graphics. And that's why I kind of moved away from it after college. I got into storage systems and I bounced around. You know, I worked with one of the early search engines thing to me and then I got over to another startup. And I met through that time period in that first startup I was doing met Larry and Sergey from Google. Because it turns out that Larry, I think it was maybe Sergey, I'm not quite sure. The very first version of the Google logo was done in the game.

7:01So they knew of us. Somehow, one of them looked me up, asked me to come interview with Google. I did back in 2001. This was when Google was three years old. Yeah, three years old. And I said, no. You did not. I said, no. Yeah. No, here's the calculation of my mind. I was like, Google's down in Mountain View. I was living up in San Francisco, and I didn't want to do the commute. So I went and worked at another startup for a year. And that one, after a year, I saw it wasn't going anywhere.

7:28They called me back up and they said, hey, do you want to interview again? I was like, sure. Like, we're not going to be able to offer you the same stock options you got before. I'm like, OK, I can't remember what it was. And I still can't remember what they offered me the first time. But I probably would have made a lot more money if I had taken that first. But I did all right. I'm not like complaining, but it's one of these things like, yeah. Now, I think back about that. I'm like, oh, a lot of good stuff came out of it. Some point along the line, Red Hat was going public. They actually offered friends and family stock during their IPO to a lot of people. We got offered for it. I made a little bit of money off that, not a lot, but it was like just after college, it was actually.

7:57quite significant at the time, you know. So I mean, there's a number of good things that kind of came out of that. And I also use the GIMP as a, you know, I was looking for like, oh, I can't afford Photoshop and here's the GIMP and it did so many things. So like, I'm sure there's so many people like you had a positive impact of being able to use this thing. And the nice thing that I, what I really liked about it is it was free, but I wasn't like stealing any software from anyone. You see what I mean? This was at a time where free.

8:25Software was not as common as today free and open source was not as mainstream as it is today Yeah, so the other cool thing I've heard from a lot of people because people still like I mentioned this like I've used it and then some people you know software engineers like I learned how to program by looking at your code And I'm just like wow that was the code I wrote 30 years ago and I wasn't nearly as good as software engineers I am now and then you got into Google second time around you said yes, what did you start to work on? Yeah, well I got in there and they said like hey, you know, this was early days 2002 was

8:55April 1st, auspicious date. Your start date? Yeah, April 1st, 2002. And I got in there and they're like, well, you know, we're going to actually build email, Google email. And it wasn't called Gmail at the time. There's a code name internally. It's called Caraboo. Caraboo. Yeah. And got in there and started working on it. And I was kind of tasked with working on the back end, threading and message storage and indexing system and worked on that.

9:21You know, pretty hardcore for the first year and a half. Actually, I was on that, I think it was three years on it through the launch, which actually happened to be April 1st, 2004. And do you remember this? There was a, it was like considering April's full joke. Yeah, I remember. So correct me if I'm wrong, but the launch said Gmail with one gigabyte of storage or something or infinite storage and I like star one gigabyte. I'm not sure what it was, but back then.

9:46Most email providers would give you about 10 megabyte of storage to free email providers and then you could pay for maybe 50 megabytes or 100 megabytes But that was really expensive this launch it looked like an April Fool's joke because who could possibly give you a free email service with 20 to 50 times or a hundred times more storage We were talking about this internally. It was like kind of a shock and awe campaign for the industry Yeah, I think it was actually four megabytes for like hotmail or yaki mail and then you had this and I did We had so much more stores, but it was indexed really fast. So it could do a search and come back almost instantaneously. Can you tell me internally, like when the project started, okay, we're going to do email for Google. How did you and the team arrive to the point of like, okay, we will offer all this storage and.

10:33We'll do it fast because this was at a time if you can take us back. But what I remember is hard drives were still expensive. They were relatively slow. We're talking HDD. We're not talking necessarily about SSD if I remember. But if you can take us, can you take us back of what it was like, what the constraints were like, and then how you innovated like to actually like do something that's never been done before. Yeah. Yeah. So at the time, Google internally had this large distributed file system called GFS. Google files. Yeah. And we were like.

11:02Basically looking at numbers and being like, yeah, we think we can build on top of this. They have a lot of. knowledge about how to do search and retrieval. It ended up being that like some of the existing systems they had for search and retrieval, they started building the prototype on there and then that was completely rewritten. That was actually what I got involved in because I got in there and there's already a prototype and then it was completely rewritten. So I was on that, you know, threading side, we decided to have message threading right from the get go, which is also kind of innovative. That was in common in email systems and spreading the message thread, which I assume needed data structures on the back and it needed like storage and

11:34You're figuring out the read intensity of those kind of things. Yeah, you know, there's some bee trees involved in that. I think that might be the second time I implemented bee trees and I think I've implemented them like a dozen times now. How do bee trees relate to email threads? It's just like you have to, you know, have some storage there where you have a thread ID, a message comes in, you have to look up. It was using the search index to match actually the subject of the message ID into the thread. And there are some other things taking place in the bee trees as well because we were getting track of the unread counts of.

12:03of threads and whatnot. So, you know, I can't even remember all the details now. This is ancient history. This is 2004. What are we in 2026? 22 years ago. So it's like left my memory, but there was definitely be trees. There was also this, you know, inverted next taking place there. All this code has since been completely rewritten. What were the economics? Like in the team, you must have done the economics of being able to offer free email, which of course I'm sure you did some math of like how it could be subsidized, but to like not make it.

12:29Terrible, terrible loss. Yeah. Yeah. Yeah. Yeah. No, I mean, we were kind of kicking around ideas and, um, you know, one of the ideas that had come up at some point was, Hey, maybe we can put ads on this. And it was one of these crazy things. So I didn't, wasn't involved in this. This is Paul Buchheit and went on to do some cool stuff at a friend feed and Facebook and ended up, I think a partner white combinator at some point, but he just like one night he was like, no, I think I can just take her to some of our existing ad functionality and incorporate it in there.

12:57And it just went like gangbusters. And there's a huge business that, you know, kind of grew up from that, which is kind of incredible. So I mean, I think there's a lot of things that it's just like, you kind of have a sense of what can be done. Like, oh, this is going to cost, you know, per user a couple of dollars per year. How do we monetize that? And, you know, we didn't want to charge for it. We eventually they did charge for it because you have the whole Google workspace stuff. But at the time it was more like, can we do this for free? Oh, it looks like it can be economical. And it took a little bit of a leap of faith. And do you remember the launch?

13:26The reason I'm asking because I remember that it was an invite-based system like not everyone could get in and I assumed that must have been to control the expected demand because again you were you're offering something for free that was paid before and it was kind of pretty obvious that there would be massive demand. How did you think about it, kind of monitor demand, decide how many people to onboard. Honestly, this is a team effort and I wasn't involved in that. I mean, I do remember being worried about like the load that would happen. And then someone came up the idea of like, hey, we should do an invite based system. And this also had like a dual role. So it kind of constrained the growth, but it also kind of drummed up this excitement. Oh, can get me a Gmail invite. I remember people asking me at the time was like, yeah, I can get you as many Gmail invites as you want. And then after you built the system,

14:13Where did you move on to? What was your next project? What was it built system? Well, there was the build system I think that was kind of all muddle to my mind because I was kind of doing that part-time when I was doing Gmail as well at some point, you know Google actually had this large monorepo I think they actually still have the money. They still have the money and they start out with the Google one Repo that was before my time then they moved on to Google to that was what was there when I got to Google and at some point we saw the the strains of Google to you and Google to was just one single monolithic make file I think it actually had some sub make files, but it was this like really large unwieldy make file and someone came to me and was like I think we could do something I'd had some interest in the build systems and I you know kind of put the Foundation in for Google 3 there was a bunch of people involved I was kind of doing like kind of the initial work on Google 3 and Google 3

14:58The initial insight was like, hey, make files kind of stuck to write. We introduced this thing called build files. And I decided to do it. It's just this stripped down kind of Python language, but it was still Python at that point. And what you can think spit out at the end was a monolithic link file, but when you didn't have to write over time, this evolved, it became.

15:17blaze internally. There's some other systems they're safe with now. I don't even know how complicated it's got. I haven't seen it for a long, long time. Then that became basil externally. It became buck. There's some other people who went to Facebook and they like, that was awesome at Google. What was the reason that make files or make didn't really work? Was it, were we talking about build performance? Are we talking about maintainability or readability? Yeah. So like, I think make itself is like, it's okay in declaring dependencies.

15:46But it's a little bit like kind of assembly language. And you don't want to write, you know, all your dependencies in assembly language. And if you didn't know what you were doing, it was easy to make a mistake and miss dependencies and whatnot. And so the kind of my the thought behind the build files is like, hey, you need to express these dependencies, but at a higher level and just like kind of cleaner semantics associated with it. And from that, you can compile down into the assembly language. And then eventually folks were like, oh, you don't have to compile down to that. We can just kind of implement, you know, the dependency kind of update engine directly.

16:13And then that's where the performance improvements were able to come in. Because at Google scale, when you have a large repo, in general, my understanding is that the reason Bazel and Buck are so popular for large code bases is it can help you improve your build performance. It gives you a lot more lovers to play around with from caching, from being smart about cache generation to obviously just raw performance. Yeah, that's exactly it. Yeah. So you kind of just dabbled and like, okay, I'll make this build file.

16:41Did that be people took that over? What was your next main focus? Oh, well, so I mentioned GFS earlier, Google File System. And at some point we realized that there were some limitations in GFS, Scalability bottlenecks, because I've been working on the storage system for Gmail.

16:55I actually dabbled in another storage system, you know, kind of a research thing. They never went anywhere. But because we're working on that, I'm going to invite to participate in like the founding team of Colossus, which was the successor to GFS. And as far as I know, Colossus still exists. It's gone through multiple iterations at Google, but it's like the second generation, you know, distributed file system. So what is Colossus? Yeah. So when I say distributed file system, externally, you might think of something like S3.

17:21kind of blob storage. It had a flat namespace, kind of like S3 give names. And there's like a minor hierarchy there, but it's like very limited. But it's not like a POSIX file system. So you don't have the full directory hierarchy. You didn't even have the full kind of permission system. A lot of that stuff got it added later. But the files are not stored on your local machine. There is a fleet, you know, kind of a service out there that has all the files, they're writing it down to their hard drives or now SSDs. And your client can access that. And it's all replicated. So if there's any crashes and whatnot, you're not losing your data.

17:49I don't know when, at some point, S3 got a ratio of coding. We did a ratio of coding in classes. That was kind of a big breakthrough. Which coding? We used Resolomon. So for the audience who's not familiar with the ratio of coding, you might think of like, I want to have replicas. And there's this thing in hard disks called RAID where it's like, I don't actually have to have full replicas. I can actually, you know, if you take A plus A and B, you can X form together and then you can have this kind of.

18:15third kind of version. And there's more and more complicated versions that read Solomon is kind of, you know, I think there's actually better codes now, but it's like one of the known ways to do this. Yeah. And we had to, you know, kind of pioneer internally, like, Oh, how are we gonna actually make this work in distributed file system? Where you focus on on latency on on being able to store data more efficiently. It's with storing it more efficiently. So in GFS, and there's varying classes where it's like, well, you're not storing two copies or one copy or data or two copies storing three triplication.

18:44three times as much storage you're having to use. And with Reed Solomon, you can get that down quite a bit lower. I can't remember offhand exactly what we used for Reed Solomon, but I think it was like essentially 2x. But you get that with also the redundancy, too. So it's smaller and redundancy is higher. So because I guess the naive thing, if you're saying, all right, I want my data to be replicated at three places, you take three nodes, three machines, physical machines, and you say like, copy one, copy one, copy one. I have it three places. Great. If one explodes, I still have two wonderful.

19:14And then you're saying that the algorithm here is you could take not three exadata, but two exadata split it smartly across machines, or maybe you could take it and see it lower. And you still have the thing where like, oh, one of them explodes. I still have all my data because it's split enough. That's exactly right. And like kind of the mental model, you know, if you just want to understand at a high level, which is essentially, you might want to say like, I want to have eight replicas of this data. I think I can't remember offhand. I think S3 might use nine. They've actually talked about this publicly. You have it.

19:43kind of nine chunks of data, but any five of those chunks can be used to reconstruct it. And what this means is you can lose any four copies and you can still reconstruct your data. And oftentimes it's more like, you know, the first five chunks are exact replicas and the other four are kind of parody ones. I've kind of forgot some of the details escape my mind, but it's along this line. But when you come up with an algorithm, you can then prove that this algorithm will work, right? Like this is a little bit like I know in software entering like a maths and algorithms a bit out of fashion. But in this case, this is really important because once you once you can prove it that this algorithm works, it will work. It will work. And, you know, it's like the math behind here is like go off fields over like gf2, something like that. I don't even know that I never actually understood the full math behind it. I always regretted not doing more math in college. But you didn't have to like read and solve and prove how this work. I think it's like back in the 1970s, something associated with like communication network. So you just take that.

20:38and kind of use that expertise, but leverage that and have to do all the engineering behind it to make it work in a storage system. And then when building a distributed storage system like Colossus, what were other things beyond, okay, you want to store data in a resilient but efficient way? What were other things that problems that you needed to solve? I'm thinking things potentially like sharding and resharding or metadata being important, those kind of things. Particularly for the scale that Google wanted to operate at.

21:07GFS kind of had this scalability limit. I believe it was like, you know, you could have a thousand machines and a GFS cluster and it kind of, which I guess sounds big until, until like today, it's kind of relatively small, right? It sounds big for two months before. And then Google was like, no, we need to have this scale up to 10,000 machines. And there's some bottlenecks. There's this GFS master as a single node. It was a bit of a bottleneck. So we're like, ah, we need to have a distributed master to store the metadata for all the objects. And Google at the time happened to have this system called Bigtable. And so Colossus

21:37stored this metadata inside Bigtable. And one of the things that I'm kind of proud and like kind of like also, you know, a little bit embarrassed by one of the design choices I went down, but actually worked out is we want to use Bigtable for the metadata for classes. And the metadata just for those of us not as into this reason, what is the metadata and the distributed file system? Yeah, it's like the names of the files and for each of the files, the files are broken into chunks. What were they 64 megabyte chunks? And then you have to have the list of chunks for each file. Yeah.

22:06And then you have to periodically, you know, the master has to be scanning over this and doing repair work. And, you know, but there's more metadata than that, but that's it in that shelf. So we wanted classes to have this, you know, kind of scalable, you know, service, big table to storage metadata. The biggest user of GFS is Bigtable. So we want Bigtable to work on top of classes. So you have the circlic defendancy. Yeah. Well, there's a bootstrapping thing, right? Bootstrap. Oh, yes. Yeah.

22:34which one starts up like you need to mark something somewhere, right? Yeah. No, I mean, the way it actually worked at the time and they've since replaced this, you know, because this is like the way to get started and leverage what you have and eventually you kind of get rid of it. But there is the kind of a foundational big table that big table didn't use classes. There's the classes using the big table and then there's the normal big table sitting on top of all work for years. So I don't even know when they got rid of that. They got rid of it at some point. But that was. But I guess sounds like you can make like.

23:04hacks that go really long knowing that they're hacks and they get you off the ground, right? They get you off the ground, right? Cause if we had to like, you know, implement that kind of big table layer from the get go, would you just delayed how long it took to get, you know, classes built? One of the things that strike me about a system like Colossus is it promises or this was internal to Google, but even distributed file systems that are external, they will promise high throughput, high availability and low latency.

23:33And to me, it's always a bit conflicting of like, well, it's pretty easy to, I guess, build a distributed file system with my limited knowledge. I could probably do something where I have either high throughput, but high latency, because whenever I write something, I write it out to all the replicas. You already, like, mentioned one technique of doing it, but how do you kind of reconcile? Like, how did you get, like, low latency while you have high throughput, while you also have replication going on the file system? Well, I mean, these distributed file systems, I mean, the latency isn't super low. I'm particularly wondering...

24:03when they're running on hard disks, which classes was doing at the time, which S3 does, you actually noticed the latency. So like S3 is a high performance system, Google, GCS, the competitor from Google, which is built on top of classes. High performance has incredible throughput, but the latency is like 20 to 30 milliseconds for first read. And that is bounded by your hard disk latency. If you put it on SSD, it gets down to closer to SSD latencies, but not actually kind of the state of art SSD latencies, which is kind of this.

24:30crazy thing that's been happening in our industry is just like how much faster the hardware has been getting. Reading it from a hard drive, maybe five to 10 milliseconds nowadays, and we never touch hard drives, reading from an SSD over NVMe 30 microseconds, 50 microseconds. So That's a microseconds. There's a thousand microseconds in one millisecond. So we're talking like a huge, huge difference. Well, there are now startups or infrastructure companies that are starting to take advantage of the fact that they can have an NVMe layer and they pull things up either predictively or not. But as you say, when the physical reality changes, you can build systems on top of it that should take advantage of it. Yeah, absolutely. The disks are so much faster with SSDs. The networks are so much faster.

25:13kind of crazy how fast like the intro zone leads these are to Google or Amazon center. And it wasn't like that. But when we were building colossus, you know, I can't even remember the numbers were but milliseconds to do a network round trip. And now it's down in, you know, 100 microseconds within a zone. I mean, I just look at these things and like, holy crap, you know, the hardware guys have really done a good job.

25:33Yeah, sometimes I feel that our software should feel way more snappy, and there are some snappy software, but sometimes I almost wonder if we're getting too complacent with all the abstractions or we're not even doing this like napkin math. Simon Erickson at TurboPuffer talks about a napkin math where it was like, all right, here's the theoretical limitation of the hardware reach from SSD might be, I don't know, 30 microseconds.

25:56And then like, how can I build a system that is as close to this as possible as opposed to the other way around saying, OK, like, you know, human will notice like 20 milliseconds, like 100 milliseconds, let's build around that. Yeah. Yeah. And sometimes like when you're architecting something, you need to think about the human kind of perceptible latencies. But oftentimes when you're dealing at the storage system layer, you know, I know Simon working at turbo puffer, they're doing great stuff over there. You have to think about machine scale.

26:21And the machine speed, which is a lot faster than human perception, like a human can tolerate maybe a hundred milliseconds of delay or if you're playing a game, maybe you need to have like, you know, frame rates of like every four milliseconds. But the machine wants much, much faster than that. So I'm going to say it's napkin math. I call this speed of light numbers. And like sometimes it's literally the speed of light bottlenecking you. The cross zone latencies between zones, cross region latencies is speed of light and fiber. You want to hear a kind of crazy fact? I love hearing crazy facts. The fastest way to send.

26:50active data across the globe is sent into space. Is it because the speed of light is faster in vacuum? Quite a bit faster. Well, it's not full vacuum. No way. Yeah. So you cover a higher distance. Yeah. Well, you actually, I believe the way to do this, you send it straight up. And then with Starlink, you send it straight up, you bounce it around between Starlink, you send it down to the other side. So you want to get it out of the atmosphere as quickly as possible.

27:13But now, if we're ever talking speed of light, this will also go, there's like a digital transformation happening, so you would need to calculate how long it takes for that system to process and do it. But you're saying that even if you do this really well, it will be faster than beaming it through an optical cable, and an optical cable slows down the speed of light, right?

27:32Yeah, the speed of light is only the speed of light in vacuum in every other medium it's slower. I was talking I did a deep dive on the hedge fund industry and they didn't tell me exactly they said that they do use satellites and microwaves and some of these things that they will not tell you because you know this is their thing but I had a suspicion that they might have found a faster way and I think this is like somewhat well-known but the details they're not gonna get into because again that but like Yeah, so yeah, yeah. They're probably balancing stuff in space. Yeah, yeah. So I mean, one of the things that they do in the high frequency train is like between New York and Chicago, it's actually not far enough distance wise to make it worthwhile to send it in space. They were doing microwave beams there. Yeah. But I mean, if you really want to get faster, you need to build like a vacuum tube between them and just like send the maybe they're doing that. Yeah. But I mean, I think that I think is like just kind of awesome about performance nowadays is I mean, there's so many layers you have to be paying attention to.

28:23in terms of performance. The rabbit hole just goes so deep there. You're almost certainly running on multi-threaded systems, right? And you're like, oh, I need to have a multi-threaded program. I need to have synchronization in there. Well, you get the best performance to just kind of avoid the synchronization. And part of this is lock-free programming, but part of it is arranging so you don't need locks at all. You need to carry about your processor caches. And there's this whole kind of...

28:45setup of caches above the CPU. Like you can think of registers as caches and you have L1, L2, L3, even your memory on the disk. And there's just you have to pay attention to all those levels. And if you do, your performance gets way better. And if you ignore it, you're like, oh, I'm not worrying about kind of kind of, you know, kind of the cache accesses, I'm just accessing data all over. Your program will just be way, way slower. And some folks pay a ton of attention to this. The high frequency trading, I mean, they do this all day long and in so many other places, like no one pays attention to it and you get this kind of gradual degradation of the performance of the hardware or the software. I did want to talk a bit more about low level stuff, but not about the speed of light, but low level data structures and programming language features.

29:30You made some contributions to the standard library, right? Well, I've done a couple. Not quite standard libraries. So, I mean, I just like have been always fascinated by data structures. It's kind of awesome. I mean, I think just the algorithms in general, you just like sorting algorithms, just kind of awesome. You could probably explain, you know, insertion sort and you know, kind of every- Could you explain quick sort as well? Quick sort's a little bit harder. Right, that's the thing.

29:55Yeah, it didn't know but but it's a smart one. Yeah. And then you get to these levels of like, you know, it's like, oh wait, someone really smart came up with this. So one of the things I worked on, just as a little bit of a side at Google at some point was a colleague came to me and he was like, you know what, we're using the STL map structure all over the place. And the STL map structure is a balanced binary tree. I can't remember if it was red black trees or one of these other balancing algorithms that any CS college students implement.

30:22And he came to me, he's like, I think we could do better because, you know, there's actually a cash problem here. Every time you're, every node you're traversing down, you're going to a different cash line. And he was thinking about using something else, a skip list to do this, which that's another awesome, awesome data structure everybody should kind of look at. But at some point I was like, actually, this feels more like a bee tree. So I'd implemented bee trees a couple of times before and figured out like how to implement a bee tree that implemented almost all the semantics of the STL map. It couldn't quite do it perfectly. And the reason is when you insert into a Btree node, you have to shift stuff around so you don't get pointer stability. This is just kind of fundamental. But if you can, you know, you don't need that for your use case, you actually can pack more data in. So the thing about Btree, like the real easy way to describe this is like, if you just have a small list of items, like eight items, the best way to store that if you want to, you know, kind of fast access in sorted order is just to sort the items, right? Literally not to have a tree at all. Yeah.

31:19for like eight items. I have it in the very simple list. Very, very, just an array, sort the array, and then you can either do a linear scan over it, you can do a binary search. And oftentimes linear scan is faster. And then you think about them like, well, if I want to store worn eight items, I could just have one node that has eight items, and then I have another node. And then you have a parent node that connects them together. And that is essentially like the, you know, you build it, you think about building it bottom up. You start with just one node of eight items. Oh, I need to insert the ninth thing, I'll split into two chunks.

31:46And the two chunks, one will have four, the other will have five, and then you have a parent node that points to them. And then you just kind of recurse on that. That's the B-tree algorithm in nutshell. Everybody go implement it. Actually, nobody should implement this anymore, because nowadays we have something else that will implement this in all the optimizations, because there's a crap ton of optimizations that you can do on a B-tree. But I just want to go back to this. There was already an existing implementation for maps. And then so your colleague looked at the code and said, I think we can do better. What I want to figure out is like in my mind, I guess someone sitting outside of, you know, I'm not involved in how some of these libraries or data structures are built, I always thought, and again, this might be naive, but really smart people sit down, they kind of look at the state of the art, they implement it, and there's no way it can be faster. In fact, I've had arguments in the past saying like, oh, let's write a...

32:38faster sorting thing. It's surely it is the fastest. But if you could bring us a little bit of how it happens and how other people like yourself and your colleague can say like, oh, what if we try something else? Yeah, yeah. So my recollection here is he was working on this kind of the big internal system. I think it was called Gaia that actually had the mapping from, you know, you log in, you have your user ID and you have to look this up.

33:06They were storing, you know, all like this, the map from user ID and email to what not to the metadata about the user in STL maps. And you just know it's like, well, there's a lot of memory usage here and it shows up on profiles. And then we're like, well, what can we do to do better? And that was kind of the genesis of it. And, you know, he happened to be working on it and he happened to be working with me, like we just started kind of noodling on this problem. Like, oh, can we do something better? And it's not one of these things like I think now with Google, they have a whole team working on their kind of internal libraries.

33:34at the time, it was more of like, you know, everybody working on their own systems and contributing to a shared base. But I guess it still goes back to what you were just saying of like, just go down the layers, try to understand it. If something just doesn't add up, like suddenly like, oh, there's this big exposure memory usage, like, you know, just ask the questions, why is this? And if you're able to or you're happy to be like, oh, can we do something about it? Right. And one of the things that, you know, he observed Leon, I think part of one of the things was it was like a map from integer ID to something else.

34:04And like, if you look at red black tree every node, you have your kind of value that you're storing in the map. And then you have two pointers. You might have an integer ID that's like four eight bytes. And then two ways. Yeah. And you look at it like, oh, that seems like a lot of overhead. And you know, just, you could use a bit. Well, the beach tree actually has a lot better. It has better spatial locality. And that's what made it faster. But it was actually smaller as well at the same time because you had less pointers involved. You also contributed to go, right? Yeah.

34:30Well, that came later. Yeah, it came a lot later. Can we talk about that? Yeah, just one of these other things. I pay attention to when there's research papers coming out about new data structures and hash tables. Hash tables are one of the earliest things you've learned about in college and data structures. How do I map keys to values where the ordering is unimportant? That's when hash tables come in. And there is the very earliest ways to do this. I've implemented hash tables multiple times.

34:57You take your key and it might be a string and you you put through a function and it spits out an integer. And then you map that into an array of buckets. And if multiple things map to the same bucket, you have to have a link. You have a link list. Yeah, this is naive implementation implementation used quite frequently. And over time, people discovered like a lot better ways to do hash tables. There's very like that's called chaining of your hash. There's another technique called open addressing where instead of actually having a linked list, you just Uh, kind of hash it again and move on or kind of walk down to subsequent buckets to find out like or subsequent slots to find out where you should be. And I remember reading about this new technique and it came out of some folks at Google. I believe it came out of their Swiss office because it was called Swiss tables. Um, I believe that's where the name. Yeah. Yeah. I believe where that's where the naming came from. Um, not 100% sure about that, but I remember reading about it. And then I was working on Go for a long period of time and Go has this built-in map structure.

35:51And it's a hash table. It's a very highly optimized hash table because the Go team is very competent. The Go runtime team and various folks have taken an attempt at like, you know, putting together a Swiss table implementation for Go. And I tested some of them and I was like, this is kind of fascinating what Swiss tables do and I'll explain how it works in just a second. But I looked at this like, well, it's really hard to beat the performance of the runtime. The runtime was really good. And I kept on a new loop on this for a little while. And eventually I ended up having to take this business trip.

36:21to India, to Bangalore. And so I was on a long flight. No. Yeah. It always starts like this. And he's just like, I'm just going to try to pull on this. I pulled on it sufficiently that I could get some of the benchmarks to be faster. Wow. And then I'm like, you know, that like is kind of like catnip for an engineer, like kind of make it all faster. Figure all the rest of it, you know.

36:40got some help from the runtime folks. There's an issue on the go issue tracker that, you know, where other people have been attempting this because people propose like, Hey, let's use Swiss tables and like the go for like, well, you know, we don't quite know all the details. You're going to have to navigate this and that. And there's some ideas there that combined them together and got to the point where it had kind of a complete implementation that was faster on, on most benchmarks, not quite all of them, but most of them. And then the go folks eventually pick this up and push it over the finish line. And then so you, you know, like you came with the idea you

37:09you got to the point where you were able to show an implementation that showed how some of the benchmarks were faster. And then you started to work with some folks on the go team too. Well, I didn't, I, it wasn't quite that. I came up with an implementation that we ended up using at my company. It was good for our use case, but actually putting it into the runtimes whole other level. But then you just showed like here is this implementation and then they kind of took the inspiration and the ideas. Yeah, they're like.

37:35Well, this is great. We want to make all, they always are looking for ways to make it run time faster. And there's like, you know. Oh wait. And then so you did this in this contribution, this is a lot of years after you left Google, right? So this was from the outside. This is awesome. Yeah. And other people contribute stuff to the outside as well. You know, we had another colleague. He contributed one of the CRC implementations, you know, adapting some stuff. CRC? Cyclic redundancy checksum.

37:58You know, Intel published some papers about here's how to do the CRC assembly very fast and contribute one of the implications. You see a number of those things where, you know, people just like are contributing externally. It's not a lot, honestly. I mean, I actually don't know the full details, but you know, people are regularly contributing to these things. Peter just described how the Swiss table work came together using an issue tracker in the gold tracker with different people contributing to the work and then the gold team pushing all of this over the finish line.

38:24This is where I need to mention our season-sponsored linear, which is a place to coordinate work between humans as well as agents. One thing I've noticed about how most of us work with agents is how it's a pretty single-player thing. You open a terminal UI, go back and forth with an agent, and it usually produces a PR. But the rest of your team has no idea what happened in that chat unless you tell them or copy the whole history. And when everyone in a team works like this, a lot of work happens that's invisible to the rest of the team. Linear's take is that agent work should be teamwork.

38:53Even today, teams already use Linear to define the work to be done. Now, Linear can already delegate an issue to a coding agent. This agent could be an AI agent that Linear integrates with like Codex or Cursor, or Linear's own agent, or a custom agent. Either way, the engine delegating stays responsible for the outcome. What I really like about how Linear works is how the work stays visible. Your teammates can follow the session of the agent, check out the PR of Producers, and join their view. We've gone from single player work to multiplayer engineering work with agents.

39:22Oh, and one more thing I like about linear, a focus on costs. Linear agents auto-routing chooses a model that is the best suited for the task. Teams can also inspect usage and instant limits, track usage, so you can use capable agents without having cost balloon out of control. Hop on board at linear.app slash pragmatic. Peter also previously mentioned Gaia, Google's internal system that map logins to users. It's not surprising that Google custom built all systems, including this one, but most of us won't build our internal Gaia.

39:49This brings us to our season sponsor, WorkOS. You can think of WorkOS as something like Gaia for the rest of us, identity infrastructure you've otherwise spent quarters building yourself. WorkOS includes single sign-on, skim directory sync, audit logs, rule-based access control, basically everything a big customer security team asks for, deliver it as a handful of clean APIs. It's how companies go from we have a login to we can sell to Fortune 500 without standing up their own internal identity platform.

40:16And Workforce is already building for the next version of the agentic authorization problem. Their newest product is Airlock, the authorization layer for AI agents. Think about what happens when you hand an agent a task like clean up the sale opportunities in our pipeline. The last thing you want is for this thing to have standing permission to delete whatever it likes. Airlock sits between your agent and the tools they call. It evaluates every request against the agent's intent and your rules, and then it allows it, denies it, or routed to a human for approval. You write down the policies in plain language, the agent never sees your credentials, and every call and verdict gets logged. It works with coding agents like Cloud Code and Codex and with MCP Gateways. So if you're working out how to let agents do real work in production without over permissioning them, take a look at WorkOS Airlock at WorkOS.com slash Airlock. And with this, let's get back to Peter and why he left Google after building Colossus.

41:11You're at Google, you're building Colossus distributed file systems. You're at this point probably working on probably the largest system on the planet. Honestly. Why did you even consider leaving? Yeah. Yeah. Well, after Colossus, I kind of dabbled in this other project called Google goggles for a little while. Remember the glass holes? Yeah. It keeps coming back. The idea, by the way. So yeah, yeah. Now it's still here present seems like Google's early. Yeah. Yeah. And, you know, I think that was a technology before it's time.

41:39I don't think it was ready to do with that point. And it looks like the actually doing the glasses is quite a bit harder. You know, the Android phones we were trying to power it on were, you know, not powerful enough. And then, you know, I just kind of got wanderlust, you know, like, you know, am I just kind of stagnating here? Which is the strangest thing to say, but, you know, the mother people feel it as well. And decided to go off and try my hand at another startup. That didn't work out. We got aqua hired by Square. So yeah, I want to pause for a second. So this company was a company name.

42:07The company that we founded is called Viewfinder. Viewfinder. Yeah. It was in the mobile photo sharing space, which should sound familiar. This is like Instagram. This was in 2012. Yeah. Right as Instagram and all the more we're taking off. Yeah. Yeah. We were right there in the play and we just didn't have the right go-to-market kind of like how to track the users, how to get viral growth kind of thing. Because from the outside, like what I read when I check, you know, the story, just like, oh, you know, you co-founded a startup. It got acquired by Square. Hooray.

42:37like it sounds like you had bigger ambitions. And this was a decent outcome, but not the dream, right? No, it wasn't dream at all. So the term I used was aqua hired. So sometimes a company will get acquired, get bought.

42:50for their IP, for their product, for their business. And other times they get bought just for the talent. The people. The people. And we got bought just for the talent. They acquired the IP, but I don't think wherever did anything with it. It wasn't kind of like where they were working. But we built up a kind of strong technical team and that's what we were hired for. And you know, like I can't remember the details. We'd raised a small amount of money. We were able to pay our investors back, make them whole. Maybe they got a little bit of a haircut. But maybe they actually got a little bit of a... That's not that we're okay. It's essentially they got their money back, which is like

43:20Like, you know, as a founder, you know, investors are big boys, they're used to losing their money, but you kind of feel bad if you lose a lot of money for them. So, you know, getting them paid back kind of makes you feel a little bit better. Yeah. Yeah. And then you, you spent a little time at the company that acquired you were just square. Yeah. And then you started issuing that little bit again. Yeah. Yeah. Yeah. Because, you know, we've been working on these, you know, distributed file systems and storage systems, you know, Clausus, one of the kind of sister projects to Clausus is Spanner.

43:48How is Spanner different to Colossus? Well, Spanner is essentially a distributed database. Colossus is a distributed storage system. And the way I think about the difference between a distributed storage system and a distributed database, you might think, oh, they're both storing data. I was about to ask because a distributed database will at some point be a storage system. So what's the difference? Yeah, so for Colossus, it was targeting large files, large append-only files. You can't update them. Append-only, yeah.

44:18large append only file. So, you know, 64 megabytes, maybe up to gigabytes in size. But if you're a database, you want to be storing like kind of small, like, you know, kind of, you know, if you're using SQL, like the relational data, you might have table, you know, billions of billions of, you know, rows, those rows are broken up into columns, the columns are typed. That just has a very different nature to the engineering challenge for database than it does for a distributed storage system. And usually distributed databases are implemented on top of some kind of distributed storage system. And that was the relationship. So Spanner was implemented on top of Colossus. And some of the design decisions in Spanner kind of directly fell out of the append only nature of the files in Colossus. You can't update a file in place. So you have to make the files mutable in your database. And this is where like, log structure and merge trees come into play.

45:09And they weren't invented at Google, but Google really popularized them with level DB, which emerged out of the work on BigTable and Spanner that got popularized into RocksDB. I subsequently re-implemented one of these things, and this is what we use in Cockroach Labs. It's called Pebble. So I'm very familiar with the internals of that. But it's kind of all based on this idea that the data is kind of stored in immutable files. So how did you decide to found Cockroach Labs? While we were working at Square, my co-founder and I Oh, there's actually three of us. Uh, we were all at square and one of them Spencer, I mentioned earlier, he was working on the gimp. He's my college roommate. And, uh, he was also a Google. He was also a Google. Um, the other guy, Ben Darnell, who was also a Google, he joined us, um, a viewfinder and ended up at square. We, you know, like, we're kind of just noodling on a project to do. And we'd, we'd actually had this design back in, um, viewfinder or like, ah, we didn't, we looked around for data.

46:02base to be using in order to build viewfinder on top of. We didn't really like the things that were out there. The technologies inside Google looked better. We had the big table, we had Spanner and whatnot. We were looking around, you know, like each base existed, but I wasn't quite happy. And there's some other systems like React and others. And, you know, at one point we're just kind of like, you know, came up with the design for Cocker to be an initial design. And I was like, no, no, guys, we're doing a mobile photo sharing site. We shouldn't build distributed, you know, database. So we put it on the back burner. Which I think was absolutely the right thing, maybe, or maybe she just pivoted away from doing the bubble photo sharing site, given the way things worked out. And then we got to Square and we saw some of the same problems that they were experiencing with data storage systems. And Spencer is very convincing. Meyers convinced some of the management that like, hey, can you just work on this part time? You know, to see if it had life behind the design, and then kind of conscripted Ben and I into it. And eventually it started getting, you know, attention externally. And we're like, hey, can we go and spin this off into a company? And that's what ended up happening. And so

46:59You started a company, but I understand you didn't raise VC funding initially, right? That was the case at Viewfinder. We did it differently. At Viewfinder, we kind of eschewed the VC money. You know, in hindsight, I wouldn't recommend that. You wouldn't recommend? Yeah, I would recommend taking the VC money.

47:19Because my experience, the VCs are very, very intelligent. They can help you navigate a lot of challenges. You know, I think sometimes there's this perception, you know, the VCs will push you into various areas. And maybe there's some bad ones out there that do the VCs I've had experience with just like some of the sharpest people, you know, I've ever met. And so you kind of have like an extra like, like.

47:37person helping you on the team. Mentoring you, giving you guidance, telling you what they're seeing. They give you advice, seeing what they're seeing in the market, where things are going that is very hard for sometimes for founders. Especially as a technical founder, right? You're focused on the engineering part. Yeah. Yeah. No, we actually took money right away for Cockroach Labs. It was almost like as soon as we left, we got and did a little road show, you know, kind of in the Bay Area. We got some interest and, you know, got an investor right away. I have to ask about the name though.

48:04Yeah, how the name of cockroach. Yeah. So, you know, we named the gimp. Yes. That was that was mine. Pulp Fiction had come out in college and like, which we named this thing, the new image manipulation program. I think we're thinking image manipulation program initially. And I'm like, oh, gimp, it's obvious. And it just stuck. At some point, you know, we're newly on this new database and kind of want to give things a name.

48:26You can't just say, oh, we're working on this distributed database. It kind of needs something. And this master is like, oh, cockroach DB, like cockroaches are unkillable. I want these things, this database to be unkillable, cockroaches is going to survive the nuclear apocalypse. So that was where the genesis was and just stuck. Whatever a bunch of nodes goes down, this thing will still be up. Yeah. Yeah. And this is where we're at today with cockroach DB. It's like one of the things that I point out.

48:51Holy crap. This is awesome. You kill a node. We did this whole campaign last year, which was really just to prove out something that already been present. The campaign was performance under adversity, but just like you can run a workload against it. You can kill a node. You can sometimes kill a whole region and the system keeps on going. And it's like stories like that, you know, like what we did on the marketing side there, but also we hear this from our customers too. They've had fires and data centers and all the other data systems go down and Cochrane TV keeps on going. I'm like, that's awesome. When you started out, who, who were company startups that

49:21who wanted to use CockroachDB. And how has it changed since? Because, you know, like just making the case like, okay, I'm starting a startup, it's a small startup. Like I will need a database and I'll, I don't, I'll split up. I'll typically choose a Postgres, right? Because it's free, everyone's using it. I'm running it on Node. At what points did you see that typical, typically tech companies are like, okay, like this is not enough for me that it's running on a Node either because it can go down or because I'm outgrowing it. What was it they outgrowing? Like I'm I'm trying to get a sense of at what point the companies tell themselves, we need something distributed.

49:57Yeah. In a database. Yeah. I mean, oftentimes we have companies calling us up after they've had a disaster. So it's like a node went up or a hard drive failed, that kind of stuff. You know, it's not quite like we're ambulance chasers, but if you see an outage, like a big outage from some, you know, company, you know, like we'll sometimes be trying to knock them up. But also they will call us, you know, I mean, like, there is a very big bank.

50:21who's now a customer. Don't think I can name them, but you can go read. They had a very serious outage due to a weather event and. after that. Which probably knocked down, I'm assuming, a region or database or a networking cable or tree fell on something. I think it knocked down a whole region. It was a region-wide power outage. It knocked down the region. And there's a mandate from the CEO. It's like, no, we just have to be able to strive these things. And that gets pushed down all the way. And you see this in other places where one of our early customers, they were running on AWS and they just got to the maximum size you can run in a Rory instance on.

50:54What would typically happen at that point is then you have to charge your database. You know, this is very standard practice. You take your single node database, you create 10 or 20 or 100 charts, and this is what Google done for some period of time. And that's a heavy burden on the application developer. And the way we always phrase this is like, I mean, application developers became a database developer at that point, and they're doing it poorly. You know, they're trying to implement distributed transactions or indexes and whatnot. We felt the burden for that belongs on the database developer.

51:21Can we talk about automatic sharding? I think it's safe to say most of us will know what sharding is when you're... But actually, let's start from manual sharding and then how you can implement automatic sharding. And if you can tell us tactics that a database like Hogwarts DB can do to actually just take that load off of you. Yeah, yeah. So I think the very basic form of sharding is a little bit like the hash table. Let's say you have a fixed number of shards.

51:46let's say just a hundred charts, your data models, a user with a lot of data, say with the user, you just take the user and you say like, oh, they map them to one of the shards. And, you know, you kind of just rely on the hash function to get like fairly even distribution. The problem with this is at some point, you know, one of your shards will get full and you have to kind of resharred. And that's a very, very onerous process. Resharding, I guess, simple way to do is like, if it's just a hard drive, I don't know per node where you write the user data, it gets.

52:13it gets full and you're like, okay, well, I now need to split it somehow. I need to move it. I need to remap it. I need to reject my metadata, which knows where this data lives. Yeah. Yeah. And depends on exactly how you're doing that mapping from like, you know, the user ID or whatever your shard key is to the shard, you might have to remap them all. Right? This is very typical. Exactly. So, I mean, this happens in hash tables where, you know, oftentimes in order to grow the hash table, you just have to essentially create a new hash table, double the size and copy all the data over. Now that's kind of like the very basic straightforward way. And there's a

52:43various levels of complexity you add on it. One of them is called consistent hashing. And there's various techniques to do this. It's kind of fasting in like how they all work. But consistent hashing, you can add an additional node, and then it only moves a fraction of the data from each chart over there. There's various systems to do that. And I believe this is like, when her lies, Cassandra. The way Cocker's DB does it is more akin to Bigtable, more akin to Spanner, more akin to HBase, where instead of actually hashing, we actually take, you know, you can imagine all your keys in a system. This is always true in any system. You can imagine there's one big contiguous key space, and then you kind of partition contiguous spans of that. And then you have to build up an index on top of those contiguous spans. And what I just described there actually sounds a lot like a bee tree. So there's this index on top that is like that maps you from, you know, like, I need to have this range, which node is it on? And this is a little bit like a bee tree, you know, you kind of squint, you know, it's like, I think you squint and everything's either a bee tree or it's a hash table.

53:40you know, that index structure. But it's now starting to make sense because I remember when I read, it might have been the Wikipedia article on Beatrice, it said, this is data structure that is frequently used in databases. It's now coming back to me because I didn't think too much of it. I'm not someone who builds databases. But now that we're talking, we just like organically keep touching on Beatrice again and again. And the other place that it comes up in databases, so this is where it kind of comes up in distributed databases and no one ever really calls it a Beatrice. I just kind of squint sometimes and I see like

54:09actually kind of a B tree. But the other place it comes up in databases is for your indexes. So if you have a table and you have like an index on your email address, and you want to be able to scan over those email addresses in order, that's a B tree under the hood in a database. And, you know, like any kind of index you have usually provides sorted order, there are hash indexes, but oftentimes it's the B tree index. And they're ubiquitous in databases, there's actually a paper called the ubiquitous B tree. And, you know, Basically, I just identified that. I think that paper was written back in the 80s and they're still ubiquitous today. They are the foundations of single node databases and pretty much every data system I've worked on has had beatries at some point in placing them. I want to ask about strong consistency. So, CockroachDB offers strong consistency. Now, for people who are a bit more newcomers to distributed systems, can we talk about the consistency models and then why strong consistency is important?

55:02And why is it hard to implement it? So I mean, there's multiple ways to kind of approach this. But I mean, if you've used a database, you've probably heard of transactions and transactions are a way to perform a whole bunch of mutations atomically. So databases talk about atomicity, consistency, isolation, durability. The durability is really easy. It's like when I write to the database, it has to be terribly written. So if anything crashes, it comes back.

55:25The atomicity is just referring to the fact I want to do a whole bunch of changes. I want them all committed or all aborted at the same time. I don't want to have like some kind of partial operation. And why is this important? Why is the atomicity important? Well, the atomicity is what gets you to the point where it's like, as an application, I can do a bunch of operations. And if there's an error, an error occurs, it all kind of gets rolled back. And it's a much simpler development model to work within. And then there's the consistency and isolation, which kind of get kind of muddled. The isolation is referring to isolation between transactions.

55:55I don't just want to run one transaction at a time. That's easy to do, right? I want to run a lot in parallel. Oh, yeah. And make it so that when they're running in parallel, they are running as concurrently as possible. But you want to have the appearance when they're running as concurrently as possible, that there is kind of a serial order to them. So this is like kind of the whole trick that kind of the gold standard for isolation is called linearizability. Don't worry about that. There's a step down from that is called serializability. And that literally refers to having a serial order of your transactions. But

56:25you're having to construct that in a way that you're doing everything as concurrently as possible. And the benefit of this, the serializability, is again, it's a very simple model for the application program. They don't have to worry about weird kind of defects occurring in their program. And some of the ones that can occur is like the classic description is of a bank, right? Where I might want to read, you know, like have an operation that reads and says like, do I have $100 in my bank account to transfer somewhere else? And you could like arrange for lesser isolation levels that you might be able to subtract that hundred dollars twice. And that's bad, right? You know, you want to keep accurate track of your bank account or, you know, within your shopping cart or, you know, it's kind of like the use cases are endless there. And you do this wrong and you have very egregious bugs.

57:10But now going back to weak consistency and strong consistency. Anything less than linearizability or serializability might be considered kind of weak consistency, but there's also like, you know, kind of strong consistency and eventual consistency. So the eventual consistency is like sometimes I can do an operation and it might not be immediately, I might not be able to see all the updates. The read result will not necessarily give me the current update. But they'll come back, you know, at some point, you know, I've written part of it and the rest of it will show up at some point. And.

57:38Oftentimes the easiest thing is your credit card balance, right? Yeah. Yeah. Yeah. And, uh, it's faster to do it that way faster in terms of just what the performance you can get out of the system. But again, it's a little bit harder for the application to deal with. One of the places this often comes up in and distributed databases or databases that have any sort of replication is that I could write to the primary replica and then I read from the secondary and it's not there yet. This is that's eventual consistency. Yeah. That's eventual consistency. And you can often work around this, but just like.

58:05puts bigger burden on the application because you have to pay attention to that. And then with CockroachDB, you have strong consistency, meaning as soon as you're writing it, when you're reading from the database, you already get the written value back. You get the written value back, you know, it's like you read whatever you wrote. It doesn't matter if you're reading from the same, you know, node you wrote it to, if you read it from another node, you still actually get the data you just wrote.

58:28Is the trade-off logically not that you would have higher latency because clearly to implement strong consistency, you would somehow need to, in the naive approach, you would need to write all replicas, right? Yeah. What are you doing inside CockroachDB? Yeah. Well, we are writing all the replicas. Well, yeah. Yeah. You're doing it fast. You're just doing it fast and making that efficient. I think this is one of the things that kind of also fascinates me about the software industry is we keep on finding ways to be more and more sophisticated in order to provide, you know, like.

58:56Do you do things that make it easier to write the applications, but do it in a very high performance way? And we've got stuff, you know, very, very good at this over over the years. And this is the area I know about the databases. This is happening everywhere. Like I'm just fascinated by how fast graphics have gotten where what I entered the industry.

59:12Like you were literally like writing out each individual pixel and now you have these GPUs that are doing like billions of triangles per second, whatever the current numbers are. And just like kind of astound, like how much sophistication I've got has gotten into every area of computer science, wherever you look at it. One more thing on cockroach DB, I want to ask about is RAF consensus. What is the RAF consensus? Yeah. I mean, consensus protocols, the original consensus protocols called Paxos, and it was famously hard to implement.

59:36raft was, you might think of it as a variant of Paxos. It was kind of like an alternative to Paxos, but in my mind today. And then because this is algorithm being that you have like a number of nodes like three to a lot more and then How do you get them to agree on? What we'll do is typically agree on. Yeah. So you agree that the right occurred. So like the way to write a consensus. So you might think I want to replicate data and I write it to a primary and write it to a secondary. And you can't actually have consensus when you only have two replicas. And the reason you can't have consensus is if there's a crash and I come up, like if I'm on the secondary, how do I know if something was written to the primary? If I'm on the primary, how do I know it was written on the secondary? Right. And you're always going to be in this kind of confusing place where it's like.

1:00:18you either have to roll back a little bit or like you know you lose some data and consensus requires at least three but you can have consensus across more than three replicas and the idea with consensus is I'm going to write to three places and normally you don't actually when you're doing a read you don't read from multiple of them but if there's a crash I have to do recovery then I'm reading Oh, I can read from two of the any two of the three. And I know I can kind of determine what had happened previously. And it's usually just on the recovery time that you're actually doing that consensus read. So reads are typically just happening from one replica. You have to write to all three. And on a crash during that kind of failure is when the consensus read occurs. And inside cockroach debut, how many replicas do you choose for your consensus? It's typically three for some system tables can be five and then

1:01:05Customers also have control of this. At the database level, you can write to five, seven, five is like, you know, if you're really concerned about the data durability, you might use five, but there's a slowdown. You know, the more you're writing to you, it's like the more storage space. And obviously, like we're talking like of the slowdown with nodes, but of course, if they're like between regions, there's now you have a lot more resilience for let's say an earthquake or power hours or whatever. But now you will have additional latency, just speed of light basics, right? Speed of light latency, right? And it's, you know,

1:01:3410s, you know, or up to hundreds of milliseconds or even higher if you're going across the globe. So, you know, you have to be very careful with that in terms of how you architect your queries. And one of the things that is just a general truism of distributed databases is you don't want to have a lot of back and forth. You want to kind of like do all your reads and one kind of parallel read set, get them back, then do your writes, right? But if you're doing like kind of serial operations where I read a row, I write a row, I read a row, I write a row. I mean, the latency is just add up. We talked about founding CockroachDB, but how has the company grown and where are you today? Yeah, yeah. I mean, we're being used in like, we're powering mission critical applications. That's our bread and butter. But by the way, can you elaborate on mission critical? Because it's like, if you're not, you are in the industry where you know what this means, but from the outside, it can feel hard to put a thumb on what is mission critical? Is my SaaS that is like showing as a mission critical? Probably not.

1:02:25Yeah. So mission critical to my mind is the other term of artist's tier zero applications. The ones that are just the core crown jewels of what's running a company, a trading system. Your trading system can't go down. If the trading system goes down, this is a critical problem for the firm that is running the trading system, banking systems. But also, we work with DoorDash. Some people might think that delivering your burrito is a mission critical system, and it certainly is for DoorDash.

1:02:55right? You know, if that goes down, it's problematic. We power shopping carts, you know, other stuff like this where it's like, well, if the shopping cart goes down, you know, that company is losing, you know, hundreds of thousands, millions of dollars per hour. So that's kind of the critical thing about it. Yeah, I guess of course that they're losing, but this is like when the other their customers are also like, they're used to this just working like running water. And then when it's not the same thing as when your utility broke breaks, right, your water or electricity is out, you'll survive. But

1:03:22It's not what you expected. Yeah. Yeah. Yeah. And everybody's like, what age are we living in that the electricity goes out? We're going to have this ingrained into our heads at Google. It's like Gmail cannot get down. People are relying on it. Search cannot go down. If it goes down too long, people are going to move to other systems. And it's not like, in some ways, search isn't as critical, except, oh, wait, every single search is out of dollars behind it. And you can actually notice the blip in the revenue. And it's not just the blip in the revenue. It's the blip in reputation as well.

1:03:51I mean, I think that's the one that really poisons companies is like, if your bank is down for a serious amount of time, the reputational damage there will be horrifically bad. And, you know, like we often talk about like, oh, and then grandma won't be able to pay her rent and she'll get evicted. You have to take this like responsibility really, really seriously. No, but also like just Gmail being measured critical just on the way here. We only exchange numbers later, but we were communicating over email like, oh, I was telling you that that you were telling me that you're here emailed.

1:04:17And I never for a second thought that it could go down. And I think we were like responding within 30 seconds, right? And it's just, I just know it's, it's there. Like I didn't like bother setting up a secondary communication line. So yeah, yeah. It's like when people just like, when you have that kind of level of trust with your users, you got to maintain it and invest in it. But then it leads to this kind of freedom for the user as well, where you just don't think about like, I don't have to worry about it. It's just going to work. And then in terms of the company, like how many engineers do you have roughly?

1:04:46We have some hundreds. I don't actually know the precise engineering number, 110, but there might be 150 in R&D overall. There's other folks besides just engineers. I'm Clare's engineering managers. Those are engineers as well. And then, you know, like we've been growing steadily. It takes quite a while to be able to distribute a database.

1:05:03not for the faint of heart. So it took a couple years. You've done it a couple of times. Yeah. Well, I did distribute a storage system. I did distribute a database. It's not for the faint of heart, right? So there's a lot of work getting it to a level of stability, then a level of quality beyond that level of stability, getting all the bugs out, and then continue to innovate and put more performance into the system, adding functionality to integrate better within.

1:05:26within enterprises, a revenue has been steadily growing over the years. And it's at this place now where we see a path to future success as well. And I want to ask you about your coding habits. So when you co-founded the company, how much code did you write for the first few years? I wrote a lot. So I've always been a very prolific coder. I wrote a lot of code early days. And early days, I mean, we were all technical co-founders.

1:05:55Ben Spencer and I, um, and we were already a lot of code and I always no exception. But you know, if like I look back at my GitHub output, you know, it's like kind of peak years, maybe a hundred thousand lines of code in a year, which is a year, which is a lot. Yeah. Yeah. No. So we're talking pre AI, pre AI, right? This is when you're back doing this manually, right? You know, at some point, you know, we started out using a system called RocksDB, which is an LSM. At some point, I think it's back in 2019. You ran the limitations with it.

1:06:25I decide we want to rewrite it and dip big push to, you know, right. That might have been like 40, 50,000 lines of code. And then a bunch of other people have come up and helped and like kind of look at that output. I'm just like, oh my goodness, that was a lot to keep in your head. It's a lot just to type. Yeah. 100,000 lines of code. The average kind of like the industry talks about is 3000 lines of code from an engineer in a month. And so if you multiply that out, maybe 36,000 in a year, that's good. Right. So I was doing a lot.

1:06:54I kind of look at that, and it's like there's kind of a max that you can hold in your head at a time. The tools have gotten a lot better since I first entered the industry. We've gotten better debugging techniques, better testing techniques, but still quite significant. And you were CTO from the beginning co-founder of CTO, but there was a time around like 2022 when you decided to kind of be a bit more hands off, right? Yeah, yeah. Can you tell me about that? I mean, the general rule of thumb for engineering leaders is Well, you got to have your team, you know, to manage your team. And we had a VP of engineering. But I was kind of getting to the point of like, OK, is my, are my coding days done, you know, like I just direct from a higher level. And, you know, I got this advice for a long period of time and I pushed back on it. But, you know, I kind of acquiesced at some point. And I think it was the right advice. I'm not saying that the advice was wrong at the time. But there was time period from about 2022 to 2024, whereas like my output declined.

1:07:49I think I actually did the Swiss tables thing in that time period, but I wasn't doing much on the the core, the business. Yeah, the core business. You know, I would get in there and do some work, but like it's really hard.

1:08:00that if you're in meetings all day, tell us to do coding. I mean, I think this is the fundamental tension. So you kind of took on the kind of the meeting burden, the coordination burden and the stuff that was, if I'm reading correctly, before you spent a lot of your head in the code and now you're spending a lot of your head like above the code, the business, the engineering or whatever customers, that kind of stuff. The customers and just being an executive as well. So very hard to wear all those hats simultaneously. And then I got back into it because AI started to emerge.

1:08:28So how, when did you get, when did you start using, when do you start to find it useful or in terms of coding? Yeah. Well, it's interesting because, you know, those initial versions of like, kind of glorified autocomplete came out and we're talking with the Github co-pilot, the cursor. Yeah. The Github co-pilot. That was the one I had the first exposure to you. We tabled with cursor at the time, but they're all like, kind of glorified autocomplete. And it was kind of crazy that you could just start typing something, you know, like the rest of the function you look at and you're like, wait, kind of got that right. This is crazy.

1:08:58Right. And, um, you know, we're trying to encourage our engineers to use this. And at some point, you know, I can't remember if this is my idea or my co-founders or someone basically like, you know, like in order to like really guide people about how to use it, you have to be a user yourself. You know, I think this is true of like engineering management in general. Like you want to like manage engineers, you have to know how to be an engineer. Like if you don't know how to be a good engineer, it's like really hard to manage other engineers. I feel like you'll have a hard time. I'm like.

1:09:25Just relating to them at the very least exactly exactly so kind of took it on me like no I mean this is like it was clear very early on like this is probably gonna go somewhere but it wasn't quite clear how far how fast it would go and You start dabbling this and I was like oh, okay. Well, it's not quite good enough It's not quite good enough. But, you know, let me start getting back into the coding very rapidly. You know, you start seeing the signs of life, like, you know, kind of the opus models coming out. It was sonnet first, then the opus. And you're like, you're looking at these and you're like, oh, wow, okay. Well, they seem to be able to do quite a lot. But, you know, the code is still not great. But then it was just like they just this cadence of continuing improvements. And, you know, I was starting to do a lot with sonnet.

1:10:09and then starting to use Opus, and I had that same movement everybody else did. And this was last year, last November. November, December, Brinter Break, right? Yeah, it was Thanksgiving. I distinctly remember it because, you know... You were not chilling, you were coding, weren't you? You were agenting. I was agenting just like everyone else. I had this thing I'd wanted to do for a long period of time on CockroachDB, which is like...

1:10:35I wanted to test all these configurations of Cocker's DB across different vertical scaling, how many CPUs you have on a node, how many disks you have on a node, how many nodes you have in the system, and test across all this huge matrix of it. This is one of these things that couldn't ever quite get prioritized appropriately, because it never seemed kind of critical, but I always had this intuition there was something there. And then over this four-day span, the code just materialized as I was using.

1:11:01I think that was Opus 4.7 or 4.5, whatever the number was. The recollection I had is, you know, I'm a pretty fast typer. And then I just remember having this feeling of like, well, the code is just like materializing before my eyes. You know, you would ask for these things. I got out of the habit of actually typing and you just kind of like ask for something materializes. Have you ever seen like some of those, you know, a movie where they have this kind of archetype of a...

1:11:27software in here gets in front of the keyboard and they start typing, show the screen. It's just like, it's going way beyond human speed. It was gone that, right? I think a software engineer is like, we used to laugh at these. I still remember Swartfish, the thing when they're visualizing, the things are going for the code appearing. You're seeing that the person's typing and then it's a big line. And a software engineer is like, we're laughing because it's not how it is. But it's crazy that effect, right? Yeah, yeah.

1:11:55But now it's even better than that effect, right? Because it actually works this time. And it's that slow in comparison. It materializes faster than that. Like you can literally go. Like we've been talking about bee trees a whole bunch. I implemented another bee tree in the past month. Of course you did. Yeah. And it took about 30 minutes to implement probably 10,000 lines of highly optimized rust. I mean, it's just like it boggles the mind. I mean, we should look up later at 10,000 lines. It's like a crazy amount. You physically cannot type that fast.

1:12:24You you started getting back to coding like are we talking about kind of vibe coding prototyping or are we actually talking you started to contribute like proper production ready code that is Up the level of what you're doing. I hope to be well it started with this tool That was like this kind of benchmarking tool that tested this matrix I am the CTO you have an office of the CTO the office of the CTO's mandate is to innovate and I was looking for places like we can have innovation And one of the things that we want to innovate in was, you know, better auto scaling of a cockroach DB cluster. And kind of in the January timeframe, I came out with like what I would think is like kind of a research breakthrough, you might say. And it came about because I was dabbling in this area and just working with models trying to understand it. And they're not just going to coding, they're also good at like helping you explore design ideas. And I think this is kind of the fascinating thing where it's you have to get out of the mindset of like, I know exactly what I'm going to build.

1:13:19Um, but more like, hey, we have this problem. Talk through it. Be a partner with me. And it'll be a sparring partner sparring partner. You know, like there's this advice you might have heard that like, you know, if you're stuck on a problem, you should go yellow duck it go rubber duck rubber duck it. Uh, I think I've heard is yellow duck, you know, go just go talk to something. You don't even need to respond. Now you can talk to the system, uh, this intelligence and it will give you back stuff and it's not always right. I mean, this is the thing even today.

1:13:47These models are fantastic. Fables fantastic. Astros fantastic. And they're not always right, but they kind of like, they know so much. It's just encyclopedia. And you can explore ideas super, super fast. And then be pointing out, well, that doesn't sound right to me. And it'll be like, oh, yeah, you're absolutely right. You know, like, I hate that sick fancy. It's like, it kills me. Or you're right to push on back. You were right to push to back on that. That's a new episode. You're right. Yeah. And yet, like, just able to make such fast progress.

1:14:14And I find it absolutely incredible. So it quickly moved from just doing kind of side things, building up some tools and whatnot to building, you know, essentially over the last eight months, it's January, we've been building towards a, you know, a new launch. And, you know, like a lot of that has been produced, the gently powered engineers and like the entire companies got on board with this now where I think it's like probably a hundred percent of engineers are using it to a greater or lesser degree.

1:14:43And a lot of code is being produced. And I think it's very high quality code. These models will not test things adequately. They don't look quite intently enough about performance. But if you're like, you can guide them in the right way. And I think there's actually a huge manage to anybody who's done management before. It's a little bit like being a manager of people where you're a manager of a large group. You're not looking to every line of code.

1:15:05But you're definitely kind of helping architect the system. I think there's a very strong analogy there. I sometimes push back on this analogy. Reasoning me, I was an engineering manager. My take is that working with these agents, it's not like management because management has so much of the human stuff. Like as a manager, when I think of all this bunch of stuff I dealt with, which was the people side of things, the conflicts between people, the performance reviews, the meeting, et cetera. And you have none of that. You do have the orchestration. Like again, this is like almost like, I guess a really

1:15:34like naive way of management where like you know they don't push back they they start to do it sometimes they're like unreliable but you know i almost like to use like orchestration a bit more because i feel management is is so much more involved like i think this is thing where like a tech lead who has no management responsibilities but they have a group of interns but they don't need to deal with their performance with their anything like it's a lot closer to that if you know what i mean yeah i i i do agree i i use the engine manager shorthand but it's really about being a tech lead for like a 30 or 40 person organization

1:16:03You know, we're being an architect for what I think that the term architect is be a little bit of a distaste. But it's been architect. He's also on the ground. A hands on architect hands on architect. And you don't have any management stuff, which is a blessing and curse. But it's kind of remarkable that you can spin these things up. If they make a mistake, you can keep on correcting them until they get it right. And we've always been able to do that on the human side. And I can do it faster. I think the ultimate result for me is you just have to be more ambitious about everything you do. You can produce more.

1:16:33higher performance, higher quality, more secure, so our ambitions have to raise up. You also mentioned that with AI, like you're ever using and you're building stuff, but also with CockWarsDB, you're now building something that is also related to AI. Can you talk about that? Yeah, yeah. We're building multiple things. I mean, AI is the future. Well, it's here to say. I think that's for sure. Yeah, I mean, like one of our PCs, which is not crazy.

1:17:00every application in the future is going to be written by AI. You know, I think there will be some kind of bespoke software, you know, handcrafted software, maybe we'll see that need to exist just as people write assembly still, you know, but it's going to be diminishing in size. So, you know, asymptotically approaching 100% of software will be written by AI generated, right? Yeah, it's hard to say if like, when it's going to end where the humans are the agent, you know, kind of like supplying the agency and the vision behind it. I think that might exist for many, many years. But like I think the code will like fundamentally be written by the AI. And I think we're going to just see this explosion of applications. And we're seeing that inside Cockroach Labs, we're seeing it elsewhere. Earlier this year, we kind of rolled out this internal platform where non-engineers could write kind of many applications. I mean, this is like, you're hearing this at other companies, we did the same thing. And over the course of just a couple months, you know,

1:17:52500 applications, a thousand applications. Buy by non-engineers. Buy non-engineers, primarily buy non-engineers. And I thought it was awesome, like, our HR team is building, like, these little applications, like, this is the thing I've always dreamed about doing, and, like, they were never serviced. Like, like, your CFO's all over the place, and ours is no exception, producing dashboards that they could never create it before. And I think it's very empowering. I'm married, I have a wife, she needs software, she cannot produce that software on her own, and I have never actually...

1:18:19helped her produce the software, which is my own failing. But I think there's a world in the future where she gets, like everyone's getting custom software built for them. And you're just going to also see greater and greater applications and higher quality systems being produced by every company as well. Today, what is your stack? What do you work with in terms of harness model? How you run agents? Is it one agent? Is it multiple? What can terminal do you use? Yeah, yeah. It's evolved over time.

1:18:46You know, like when I first started dabbling the AI stuff again, it was, you know, GitHub co-pilot. It was an Emacs user for like 20-something years. I convinced them to move to VS Code. But that's all gone now. At some point, I moved to using Cloud Code. That was the thing that whatever reason I just got started using it was Cloud Code in the terminal. Of late, I used a mixture. So I'll just grab my current setup. I use the Cloud Desktop app, Cloud Code via the Cloud Desktop app. It's fantastic. Good job, Anthropic. I also sometimes use the Codex.

1:19:15desktop app, just so I have an alternative model to turn to, for some very critical things we're working on, I will get, you know, one of those models, sometimes like the best model, oftentimes I'm using the best model like fable, you know, I've recently started using using that sometimes this Astra, sometimes this the other ones, but you like you have one producer design, you have the other one being like, hey, my colleague produces, can you kind of tear it up, you know, adversarial review it. And it's not always perfect, right, you know, but I think there is utility, especially for something that's super, super critical.

1:19:43We're pushing towards the launch really soon and kind of rushing towards the finish line. I'm telling folks on the team, it's like, you know, especially our very senior folks like you should use the best model right now. It's worthwhile to do that. I'm generally just using the best model. And part of the reason is I don't actually know that I'm getting a lot more intelligence from it, but I don't want to have the cognitive overhead of deciding on a case by case basis. Yeah. Should I use sonnet? Should I use opus? Should I use fable? Should I use solar astro? And I think, you know, maybe if you like I really need the speed.

1:20:13I would make that decision. But oftentimes I'm like, I'm doing things in parallel. So you're asking how many agents I'm spinning up? Well, it depends. Like oftentimes there's like a certain number of sessions you might be using. I find my kind of cognitive overhead is about I'd 10 sessions and currently, but sometimes those sessions will have many sub agents doing these things. And they'll be long running. Yeah, it'll depend on what I'm doing.

1:20:37As I was coming here, I was on the train, I spun up something to do a little bit of research, and that was just probably using three sub agents. Other times it might be 20 sub agents, you know, with the anthropic has dynamic workflows. I can't remember what the codex thing is called, but they have various ways of spinning up kind of graphs of agents and, you know, prosecuting them. I mean, I think it's sometimes I'm probably using 100 sub agents, others it's only like five and depends on what was happening. And sometimes I'm not doing any of that agentic stuff because I'm often thinking about something else.

1:21:05Since you were an Emacs user for 20 years, you know, using the terminal, right? Well, Emacs, but how come you move to graphical interface with agents? A lot of people still use terminal UIs. Yeah, yeah. Well, I, so I moved from Emacs to VS Code. I was just like, a colleague was like, Hey, these IDs are really good. You need to try them out. I was like, Emacs is an ID. And then I kind of moved and like, you know, some of the stuff is just more seamless and like Emacs keeps on catching up. It always feels a little bit.

1:21:32you know, six months to a year behind. And like every time they have a new version, my setup would break and I just got tired of that. So I moved to VS Code, but then I was like, I'd have many terminals open in VS Code. My setup would always be like terminals in VS Code tabs, the terminals and tabs, you know, have like aided them open. And then they start taking over used to be like just cloud code in the terminals. Yeah. Yeah. And that, you know, just some point recently is like six weeks ago, a colleague was like, Well, if you tried out the cloud desktop app recently, it's really good. I was like, yeah, no, no, I'm very, very happy. And I made the switch and it's a little bit awkward at first. And then suddenly I'm like, holy crap, this is awesome. You can like manage the agents a bit better, easier sessions. You have the sessions there, the sessions and down the side, you know, it's like they're kind of like tabs in some regard and shit. But the whole integration that Anthropics has been doing, opening eyes doing the same thing now. By the way, like I'm not just in cursor and factory and cognition, they're all pushing the same thing. It's.

1:22:26Incredible how fast these systems are innovating right now and evolving. What do you think good software engineering looks today compared to like, you know, four years ago before we had a has it has it changed has good change or that's not really changed. Yeah, I think the ambition has to increase, you know, I think quality has to be higher security has to be higher. I'm glad you mentioned quality. Can we talk about that? Because I'm seeing across the industry just Quality declines, which you cannot fully put your finger on AI, but oftentimes it is people pushing out more and more and just not paying attention to just small regressions here and there. Again, like you're building a database. Yeah. Have you noticed any or have you got a feedback of any quality regressions or if not, like how come? Because like when, like this is just basic, you know, like we talk about the law of physics, this is.

1:23:20observe thing that when you start to have more output you increase your deployment frequency you often not always but you often have like more regressions and more bugs. If you produce a certain number of lines of code you're probably going to have a certain number of defects per line of code and now you can produce more lines of code so you probably would have more defects right but the thing that pushes against that is that you can be telling these agents you have to give them quite a firm hand at this. This is the thing that I hope the model providers are listening to. But you need to give them quite a firm hand. They kind of get a little bit lazy on the testing side. And you have to make sure the tests are comprehensive. But also they're using all the testing techniques. And there's a lot of testing techniques out there. We have a lot of knowledge about how to do testing well. And you know what? The agents are lazy. Humans are a little bit lazy.

1:24:09So getting the humans to actually be very disciplined about their testing is also challenging. And I think it's actually easier with agents, you know, you can kind of instill that you can get them set up. You have to give them the guidance, use property based testing, use metamorphic testing, use like these advanced testing techniques, deterministic simulation testing, you know, there's like technique after technique can use. And humans have always like, I'm lazy myself, like I'm pretty good about being disciplined about testing at some point, you're just like, okay, that was enough, we got a ship.

1:24:37And like now you can get a little bit like, you know, a little bit stricter and firmer. I think the same thing applies over on the security side, the performance side. I mean, we've always had, at Cockroach, in the industry, we've known security coding practices. You can literally have every single line of code on every commit reviewed by a security expert. Doing like an adversarial security review by an agent or multiple agents. Or multiple agents, right. We're going through a tough time in the industry right now with like kind of Hacks and security leaks and whatnot. There's only a limited number of bugs that can be in software I think we'll get it you know out of it on the security side and on the quality side and then also just on the point when I say quality such as bugs But it's also like you know, just a little thing It's like oh that UX element is wrong and there's no excuse for that right now like fixing it is so so easy and What we're also starting to see of all this like you know designers using Sigma Well, I think that should be a thing of the past right now our designer

1:25:32just deals with HTML and CSS and JavaScript directly. And sometimes is even just producing pull requests, you know, PRs, which she loves. We all love. Everybody's happy with this. There's none of this waterfall. So she's producing pull requests for the production code base. Yeah. Yeah. And, you know, this is on UX side, not on the core database. Of course. But this is the area that she owns, right? Yeah. Yeah. It's just, I mean, she loves it. Everybody loves it. I mean, there's no downside. This is not new. Yeah. For sure. Yeah.

1:26:02What about code review? What's your take on code review? I think it's pretty it's starting to get a bit controversial like is it going to stay or not because it's been a practice that's been around like Think about I mean you you worked at Google Google has been so big on code review as I understand their use there are two code reviews right the The domain expert reviews it and then there's a language expert reviews that so you went through that How did you think of it and how are you thinking of it now? I used to be part of the I was one of the early members of the C++ coding I'm asking the right way. Okay. You will have strong opinions. Tell me. Yeah. Yeah. I mean, I see that code review, I think was fairly essential before the age of AI. But now we're getting to the point where I'm reviewing and looking at code. I look at most of the code that the agent's producing still. And yet it's like you're not giving it the same level of scrutiny, right? And this has always been the case. If you get a poor quest from a junior engineer, you have to give it more scrutiny than if you get it from your most senior engineer.

1:26:58And you ask any tech lead, any engineer manager, any software, they'll say, yeah, yeah. So the junior engineer or someone new to the code base, you just have to get more scrutiny. And what I'm finding is the agents are getting better, you're having to give less and less scrutiny. You do have to give scrutiny to some things. It's like I said, it's like the testing will be incomplete. And maybe they didn't follow the security stuff. Maybe there was a performance regression. And I think it's like assuring there's constraints on the system. So it's hard for them to do the wrong thing.

1:27:27I suspect that, you know, I don't know if it's going to be this year or next, that we're materially going to stop looking at the code in the same way that we don't look at assembly anymore. We trust a compiler to produce pretty good assembly. We trust the compiler to produce good assembly. Unless you're one of those people where it's really important, you're maybe a game developer or someone and you look at it, but there's fewer and fewer of those folks. Yeah. And even then, I think what will be migrating to is Why does the human have to look at the assembly? The AI should look at the assembly. Like I'm doing something right now where I want to have a zero overhead abstraction, you know, for doing something that is done at test time and when it's in correction is compiled out. They will set up for me a little system where he actually looks at the decompiled code to verify like that there's only a few extra instructions put in place.

1:28:17I never would have put that in place, but now it has this guardrail that every time it changes this, it can verify that there's no regression. And I think you're going to see more and more of this where you kind of put guardrails in place. I think the model kind of likes it because it can work within that guardrail. Now, for what, like 20 plus years, you were writing so much code, like I'm sure you were in the zone. You remember being in the zone and just turning it out. You wrote a lot of like production ready code. Now that you're coding with AI, like.

1:28:46Do you get into the zone? Yeah, absolutely. And how is that zone? Is it the same? Is it different? It definitely feels a little bit different. It's maybe a little bit less intense, but you're managing more things cognitively. Can you describe what is it right now when you're in the zone? Yeah. Well, I'm thinking of ideas that normally would have taken me a week to experiment with.

1:29:10I think multiple of these experiments and then I fired them off all simultaneously and then I'm kind of like reviewing like what else should I do while that's being complete. Sometimes I'm kind of reviewing like they'll be giving me progress updates of like oh hey this is coming in we're seeing this stuff and I'm being like that doesn't sound right hey what about this or did we do this you know correctly you know maybe I had design and it's not implementing the design quite perfectly but I have this little feeling that you know I haven't been a college professor but maybe I remember that was a you know.

1:29:36If I was a college professor and I had a whole swarm of research assistants and they're all got off doing things and it's coming back, but it's coming back just really rapidly. You're not waiting months or weeks. I'm not waiting months or weeks. And then I'm iterating like, oh, that one failed. That's fine. You just got to let go. And this is the nature of the software I build. I think there's other pieces where it's like you just whip out a website. You can whip out something that doesn't have this level of kind of scrutiny very quickly.

1:30:01But I talk about this in the I have a whole bunch of analogies about like the Let's talk about it. What analogies do you have about using AI or AI? The one I was advocating for had kind of two that I was advocating for like late last year and this year, which is, you know, AI is coming for us. It's here, right? And it's like, you know, you're producing software, you're like walking down the road. And sometimes, you know, someone will pass you there running, they got an efficient gate and whatnot, but everyone's under their own locomotion.

1:30:30The these agenti coding agents came and it was like a car pulled up next to you and get into the car. You don't know how to drive. You don't understand the controls, but you got to get in and start. You forgot the gas pedal and it takes off and crashes into a tree. But you have to learn how to drive. You know, I think using all these coding tools, it just doesn't just happen naturally. It's learning how to drive. I think we might be in the era of F1 driver right now, which is like the really good people can drive these systems a lot harder, a lot faster than the people who just picking them up.

1:31:00If you've never used an authentic coding tool, there's a vast difference between someone who's like really expert in them, knows where they break, can pay attention to that versus someone who's just picking it up for the first time. One analogy I've heard is we used to talk about the next engineer. You remember, like this used to be a debate for a very long time. Is it or is it not? But now what I'm hearing is the hundred X engineer. Yeah. And so you're saying that you are seeing some folks who maybe let's not use the hundred X engineer, but like this, like.

1:31:30F1 driver who was just really really good at it. Like how would you describe a person who you've seen this? Is it just like rock solid engineering basics and they picked up they lean into using these tools or what do they like? Yeah, I mean there is quite a bit of a it feels like you know it's directional that they're good software engineer before. I mean I sometimes think it's like you know everyone's in this kind of spectrum of capability of software engineering and this is just like you know taking that line and spread it out.

1:31:57And it's not quite true, you know, I think it's helped some people more than others, but, you know, it feels like it's just stretched it out. So, you know, your ability before is now amplified. I'm always interested to learn that, for example, Boris Cherny, Tebow at OpenAI, they both have been really, really good software engineers. Boris wrote one of the first TypeScript books, the first TypeScript book for O'Reilly. He built some massive system, same with Tebow, who built it. And now you're kind of seeing, oh, these people are building all these tools and innovating, like, yeah, they They're really good before. Yeah. Well, I mean, this is, I mean, I have two other analogies to give you about like the, what it feels like in AI. You've undoubtedly heard about the term pair programming. And pair programming. Yeah, pair programming. You know, and the idea behind pair programming is it's good to just like, you know, have one keyboard, one monitor and two engineers at it and one at the keyboard and the other one sitting beside them kind of like looking over the shoulder and giving guidance. And I think there's an aspect of that feeling where

1:32:51I actually got Chatcha P to do a little image of this where it's like the Android is at the computer typing and you're just there giving instructions. But that was maybe the way it felt like a year ago. I think it feels a little bit different now. The one I just started recently saying is that I feel like the domain experts, the people who are really strong before are now massively amplified.

1:33:11Have you seen all this mathematical stuff coming out like the crazy proofs? Well, I don't understand it, but I don't understand them either. Yeah. Yeah. So I told you I wasn't very good at math. You know, it's not complete. I just was like, I stopped in the freshman year of college, right? Yeah. But, you know, I kind of like watch along with these advancements. And, you know, Terence Tao, he's like probably the most famous living mathematician, you know, super genius. He actually posted this session. There is this recent breakthrough. It's called the Jobin conjecture.

1:33:37I don't even know what it meant but he posted this chat GBT session where he's interacting. I think it was chat GBT and you could see him interacting with this intelligence and it was crazy because he's talking to it as a peer colleague and it's responding and literally it honestly looks like I'd encourage everyone to go look this up. It looks like you know almost a foreign language.

1:33:57It's like his domain expertise is getting amplified by the system he's interacting with. You can see how he's like kind of learning and exploring ideas just really rapidly. Now there's all this controversy about AI mathematics, but I feel like the analogy that comes to mind to me though is the domain experts, they're a little bit like sorcerers in their particular domain. You know, you have the earth sorcerers, the earth wizards, the water ones, whatnot. And if you know the magic incantations, the right words to say the right order, you actually get something kind of magical.

1:34:26And if you don't, you just get sparkly stuff that doesn't have anything there behind it. You know, you would probably make, you don't know much about distributed databases. If you're going to ask Fable or Astra, build me a distributed database like CockerDB, you will get something out, but it'll kind of be ultimately hollow inside. But if you're an expert in databases, and you have to build distributed database, and you can point out all the various things you have to know about distributed database, here's what you have to worry about the storage layer, the networking layer, here's the various data structures and runtime inside. You can actually get something quite magical, very, very rapidly out of it.

1:34:56What would your advice be for engineers with like mid-level to senior level who have been figured out how to do coding to become strong engineers in this age of AI? Well, the first off is you have the most amazing tutor kind of readily at hand. And I mean, one of the things that I would always do throughout my career, And now I've kind of stopped doing it, but it's like the reason why it's going to become obvious, which is like, I would always look at other people's code. So I always said, you know, Google early on, you probably heard of Jeff Dean. Jeff Dean was amazing coder, his colleague, Sanjay Gamalot, also just an incredible coder. And, you know, I would be looking at their poll requests. I'd be looking at their changes. It wasn't called poll requests at Google. There's a different name for it. But I'd be looking at my CL, right? Yeah, CL.

1:35:49This is a p4 is a different version control system, but I'd be looking at their changes be like how'd they do what they did, right? Be looking at their code. Oh my goodness, aren't these codes really always very elegant? You know, just as high performance. How's he doing that? You know, like, how's he going about it? And it's almost just like you acquire via osmosis. But now what you can do is not just acquire via osmosis, but you can really like, I mean, I would be encouraging if you're a junior engineer, you know, there's a senior engineer nearby, like you could ask him how they're doing what they're doing, but you could just ask the AI to dissect what they've done.

1:36:19and explain it to you and explain to you at various different levels. Like, how does this code work? What is it doing? Give me a diagram, explain it to me like I'm five, explain it to me like I'm 10, explain it to me in French, whatever you want. I mean, fundamentally, to some degree, AI is a translation tool. They translate it from whatever kind of language or understanding it's in.

1:36:39and keep on integrating it till it increases your understanding. You were saying how domain experts are very much amplified. I guess one strategy as a software engineer is like obviously become a great software engineer and use it as a tool. You can get a lot faster. You can get at distributed systems like I'm not a distributed databases expert at all. But I use AI to explain a few things for me to understand a front which was very helpful and it would have taken me a lot longer time beforehand. So I can use this.

1:37:07But I wonder if there's another part of like as a software engineer, you can use it to become more of a domain expert wherever you're working. If it's a payments company, I mean, use it to learn about payments as well. So you can help the business. You can help your team. And honestly, you'll just learn more, right? Yeah, I think, you know, I would encourage everyone you have to have a little curiosity, right? Don't don't be bound in by, you know, the area you're working on, explore outside of it. You know, I was working on Gmail, but I was fascinated about how like that the main Google search engine worked. I was fascinated by like how the internals of big table worked, even though I wasn't directly working on a big table, just explore in, look at those things. And now it's so much easier because you have this super advanced patient intelligence there to explain it. Like, why do you think it was done this way? And then like, I mean, once you become an expert, you can be interrogating. Well, I see this on that way. Why don't we change this? Would this be helpful? And, you know, that's where you go from just kind of learning to actually contributing back.

1:38:00I think everyone has to have the personal agency to do this. You know, if you're just sitting there waiting for someone to educate you on how to do this, it's going to be really hard right now because anyone who's coming in explaining how to use AI or explain how to be a better software engineer, they're going to be out of date, right? You just got to get in there, be using this tools all the time yourself and using it like easy to learn. I feel like I've learned more in the past, probably even year than the previous five years combined.

1:38:26Just weird. Given your trajectory and given the environment you were working in, right? I mean, like, everybody's been in the industry for a while. Like, I'm definitely a better coder. I was a better coder 10 years ago than when I first got into the industry. It's like, I can look back every decade and realize, like, I got a lot better. And I feel like I just got a lot better over this past year. And this was also one of the reasons I was really excited to talk to you, because when we started to just exchange your messages, the first thing you wrote to me, and I asked you, like, hey, you know how

1:38:53How are things going? You said like you wouldn't believe, but my coding output is insane and it's high quality and it's database quality level. And those were the things I don't really usually see it. I usually see, okay, I'm not producing more code, but it's slop. But again, like to me, this is a bit of an inspiration. Like, look, like you can use these tools to just like amplify yourself as a software engineer. Like you are one example, right? Yeah, hopefully with a many. Yeah, yeah. No, I'm not the only one in Cockroach Labs. We have other people doing this as well. I find it very exciting, you know.

1:39:22It's a little bit exhausting right now, but it's very exciting. Like, I got into software engineering because I like building stuff. I can build stuff faster, you know, the stuff you might have had to compromise on in the past, and then you can take away some of those compromises. I mean, you see this in the UX of software coming out. I think the UX is a lot higher. See all the fancy like web animations and whatnot. That's only just like the surface level. It just extends way, way below that. Peter, this was awesome. Thanks for coming on a podcast. Yeah, this is wonderful. Thanks for having me.

1:39:50One reason I was excited to talk to Peter is because he's been a very high profile and productive engineer in pre-AI, building some of the most resilient distributed systems in production. CockroachDB is known for its resilience and how even if several nodes are destroyed, the database still operates with that data loss. Basically, it's as hard to get rid of as cockroaches are, hence the name.

1:40:09One interesting part of our conversation was how Peter built more efficient data structures than the standard coding libraries had, thanks to him and colleagues paying attention to parts of the library that seemed slow. He did it for the C++ STL map and then go for the swiss table implementation. I found both stories a good reminder that you can improve the existing library or even the language, especially if you measure which parts feel slow. Another part of his conversation that I liked was how Peter came bit of a full circle.

1:40:35He used to write 100,000 lines of code per year, being a very productive engineer and CTO. He then stopped writing code aiming to coach engineers between 2022 and 2024.

1:40:45and then he started to code again because with AI tools, he wanted to coach his engineers better, but it's hard to do if you don't use the tools yourself. And now he finds himself being extremely productive, and this time, the team around him is productive as well. And we're not talking about vibe-coded software, but database-worthy, high-quality code generated and committed to production. Peter is convinced that AI amplifies existing expertise, and this is one reason why he probably learned more this last year, building with AI, than the previous five years combined.

1:41:14And I find it a valuable reminder that learning and building deep expertise in software engineering, this is very valuable. And as closing, I appreciated that Peter said that not only is he excited, but he's also exhausted. There's a lot to learn, but it's tiring and neither him nor anyone I know is immune to this. So if you're also exhausted with all of the things going on with AI, know that you're not alone. Check the show list for more of the pragmatic engineering deep dives on Google's engineering culture and on distributed systems.

1:41:42If you liked this episode, please make sure you're subscribing to our podcast player and a special thank you if you leave a rating. Thanks, and I'll see you in the next one.