# AI-Driven Engineering: Cockroach Labs CTO's Strategy

**Podcast:** The Pragmatic Engineer Podcast
**Published:** 2026-09-30

## Transcript

He built the 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, for the last 30 years, I've always been a prolific coder, but my current output is a bit insane.
And this isn't Vibe Coded Junk, but database-worthy, high-quality, high-performance code, thanks to working with strong coding models.
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.
why 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 TurboBuffer.
a 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're calling Teepuff V3, demands some hardcore systems engineering and they're building it in public, sharing design decisions and benchmark results as they ship.
They're keeping a work log of their journey, and the first post just dropped today.
Follow along at turbopuffer.com slash v3.
That is turbopuffer.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 kind of 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 like early on, my mom.
did programming at ibm at some point i'm never even quite sure what she did but we had computers always around our house like apple 2 plus apple 2gs i'm from that era um on up and you know go to the live uh the bookstore i'd find a book on basic or magazine type in programs no idea what i was doing but you know just kind of like i was addicted to like you can produce put stuff into these computers and 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 Following the footsteps of my dad.
Oh, you started mechanical engineering as your specialization?
Yeah, as my major.
And I got in there and I was like doing, like I'd done some computer stuff before.
It was a real foolish move to do this.
But first semester of doing these homework assignments in mechanical engineering, 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 everybody almost was failing it.
I'm like, I'm in the wrong field.
Let me switch.
and then you switched.
Then I switched, yeah.
What was the first software that you built, either at college, it must have been at 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 roommate in college, we had this course, what was it, a compiler's course?
I'm not quite sure anymore.
This is like 30 years ago.
And we were kind of bored with it.
So we wanted to do something like kind of fun on the side.
And I'd done journalism in high school in my junior and senior year.
I knew stuff about kind of computer graphics and wanted to do something like Adobe Photoshop.
So 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.
definitely people still know me and it uh it led to other some interesting uh events in my career and 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 And it's one of these things you almost kind of need to be a little bit naive to start anything like that.
Because if you know how hard it's going to be, you would never start it.
So I think there's this like you have to have this level of like if you're really truly wise about the effort, you like never get into it.
But then when you get going, it just keeps on snowballing.
It gets far further 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 GIMP, 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.
Getting to the point where we're like, we should release this to the public.
And back then there was 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, oh, that sucks.
I guess we'll just keep on working on it.
It's been fun.
And then we release the GIMP.
Never heard from this other guy again.
And I just took a little lesson with 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 the marketing behind some of that stuff that you might hear is like, I mean, I don't know if we like, we stole his thunder.
I'm not even sure what happened.
Never traced down what happened, but there's a real lesson there.
So there's a.
possible future where you read this announcement where someone's 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, you know, it sounds like just do your thing.
Put 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.
They're just like whatever they can't get going on their idea.
So, you know, I wouldn't be concerned at all.
It's 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.
And what were some fun things that the GIMP led 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 at one of the early search engines, Inc.
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 GIMP.
So they knew of us.
Somehow one of them, you know, looked me up, asked me to come interview at Google.
I did back in 2001.
And this is 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 in 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 like I saw it wasn't going anywhere.
They 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 friends.
I made a little bit of money off that.
Not a lot, but it was like just after college.
It was actually.
quite 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 used 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.
software was not as common as today.
Free and open source was not as mainstream as it is today.
Yeah.
And then the other cool thing I've heard from a lot of people, because people still, like I mentioned this, like, oh, I've used it.
And then some people, you know, software engineers are just 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 a software engineer as 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.
April 1st, auspicious date.
Your start date?
Yeah, April 1st, 2002.
And I got in there and they were 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 codename internally.
It's called Caribou.
Caribou.
Yeah.
And got in there, started working on it.
And I was kind of tasked with working on the backend threading and message storage and indexing system and worked on that.
you know pretty hardcore for the first year and a half actually i was on to maybe it was three years um on it through the launch which actually happened to be april 1st 2004.
do you remember this there was a uh it wasn't like considering april's full joke yeah i remember so correct me if i'm wrong but the the launch said gmail with one gigabyte of storage or something or infinite storage and like star one gigabyte i'm not sure what it was but back then most 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 100 times more storage we were talking about this internally it was like kind of a shock and awe campaign for the industry i think it was actually four megabytes for like hotmail or yaki mail and then you had this and not only that we had uh so much more storage but it was indexed really fast so you know you could do a search you know come back almost instantaneously but can you tell me can you tell me internally like when the project started okay we're gonna do email for google how did you and the team arrived to the point of like okay we will offer all this storage and We'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 to actually 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 File System.
Yeah.
And we were like...
basically 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 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 wasn't common in email systems.
And threading to have the message thread, which I assume needed data structures on the back and it needed like, you know, storage and.
figuring out the read intensity, those kind of things.
Yeah, you know, there's some B-trees involved in that.
I think that might have been the second time I implement B-trees, and I think I've implemented them like a dozen times now.
How do B-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 or the message ID into the thread.
And there are some other things taking place in the B-trees as well because we were keeping track of the unread counts of...
of 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 B-trees.
There was also this, you know, inverted index taking place there.
All this code has since been completely rearing.
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.
Terrible, terrible loss.
Yeah, yeah, yeah.
No, I mean, we were kind of kicking around ideas.
And, 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 wasn't involved in this.
This is Paul Buchheit.
Went on to do some cool stuff at FriendFeed and Facebook and ended up, I think, a partner at Y Combinator at some point.
But he just, like, one night he was like, no, I think I can just take out some of our existing ad functionality and incorporate it in there.
and 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 like oh we think this is going to cost you know per user a couple dollars per year how do we monetize that and you know we didn't want to charge for it 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 uh it took a little bit of a a leap of faith and do you remember the launch The reason I'm asking because I remember that it was an invite-based system.
Not everyone could get in.
And I assume that must have been to control the expected demand.
Because again, you were 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 it played dual role.
So it kind of constrained the growth, but it also kind of drummed up this excitement.
Oh, you 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, after you built the system, Where did you move on to?
What was your next project?
Was it the build system?
Well, there was the build system.
That was kind of all muddled in my mind because I was kind of doing that part-time when I was doing Gmail as well.
At some point, Google actually had this large monorepo.
I think they actually still have the monorepo.
They still have the monorepo.
And they started out with the Google one.
repo that was before my time then they moved on to google 2 that was what was there when i got to google and at some point we saw the the strains of google 2 and google 2 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 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 uh 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 uh the initial insight was like hey make files kind of suck 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 gconfig spit out at the end was a monolithic make file but one you didn't have to write over time this evolved um it became Blaze internally.
There's some other systems that are associated 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 Bazel externally.
It became Buck.
There's some other, you know, people went to Facebook and they were like, that was awesome at Google.
What was the reason that MakeFiles or Make didn't really work?
Was it, are 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.
But it's a little bit like kind of assembly language.
And you didn'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 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.
And then that's where the performance improvements were able to come in.
So like, because I Google scale, like when you have a large repo in general, like 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 levers 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 dabble and like, okay, I'll make this build file.
did that people took that over but 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 I actually dabbled in another storage system, you know, kind of a research thing that never went anywhere.
But because we're working on that, I'm going to buy 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.
Kind of blob storage, it had a flat namespace, kind of like S3, you 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 in 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 and 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.
I don't know when at some point S3 got erasure coding.
We did erasure coding in Colossus.
That was kind of a big breakthrough.
Which coding?
We used Reece Solomon.
So for the audience who's not familiar with erasure 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 and B, you can XOR them together and then you can have this kind of...
third kind of version and there's more and more complicated versions that reed 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 the known ways yeah 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 were you focused on on latency on on being able to store data more efficiently it's storing it more efficiently so in gfs and there's varying costs as well it's like well you're not storing two copies or one copy of data or two copies storing three triplication three 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.
I think it was like essentially 2x.
But you get that with also the redundancy too.
So it's like it's smaller and the 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.
And then you're saying that the algorithm here is you could take not 3x the data, but 2x the data, split it smartly across machines, or maybe you could take it and take 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.
Or I think, I can't remember offhand.
I think S3 might use nine.
They've actually talked about this publicly.
Yeah.
kind 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 that escaped my mind but it's along this yeah but but 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 i know in software engineering like 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 um you know it's like the math behind here is like claw fields over like gf2 something like that i don't even know that i never actually understood the full uh math behind it i always regretted not doing more math in college but you didn't have to you like reed and saw them and proved how this work i think it's like back in the 1970s something associated with like communication network so you just take that and, you know, 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 re-sharding or metadata being important, those kind of things.
Particularly for the scale that Google wanted to operate at.
GFS kind of had this scalability limit.
I believe it was like, you know, you could have a thousand machines in a GFS cluster and it kind of...
Which I guess sounds big until like today, it's kind of relatively small, right?
It sounds big for most people.
And then Google was like, no, we needed 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.
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...
stored this metadata inside Bigtable.
And one of the things that I'm kind of proud and 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 distributed system, what is the metadata in a 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.
And 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 a nutshell.
So we wanted Colossus to have this, you know, kind of scalable, you know, service, Bigtable, to store its metadata.
The biggest user of GFS is Bigtable.
So we want Bigtable to work on top of Colossus.
So you have the Cirque look dependence?
Yeah, well, there's a bootstrapping thing, right?
Bootstrapping, yeah.
Oh, yes.
Yeah.
Which one starts up?
You need to mock 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 Bigtable.
That Bigtable didn't use Colossus.
There's the Colossus using the Bigtable, and then there's the normal Bigtable sitting on top of Colossus.
And it all worked 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 it sounds like you can make, like, hacks that go really long knowing that they're hacks and they get you off the ground, right?
They get you off the ground, right?
Because if we had to implement that kind of big table layer from the get-go, it would have just delayed how long it took to get Colossus 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.
And 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 mentioned one technique of doing it, but how did you kind of reconcile?
How did you get low latency while you have high throughput while you also have a replication going on file system?
Well, I mean, these distributed file systems, I mean, the latency isn't super low.
when they're running on hard disks, which Colossus was doing at the time, which S3 does, you actually notice the latency.
So like S3 is a high performance system.
Google GCS, the competitor from Google, which is built on top of Colossus.
It's high performance, has incredible throughput, but the latencies are 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.
crazy thing that's been happening in our industry is just like how much faster the hardware has been getting.
Reading from a hard drive, maybe 5 to 10 milliseconds nowadays.
I 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, like 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.
I mean, just.
Kind of crazy how fast like the intro zone leases 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 what the numbers were, but milliseconds to do a network round trip.
And now it's down in, you know, a hundred microseconds within a zone.
I mean, I just look at these things and I'm like, holy crap, you know, the hardware guys have really done a good job.
Yeah, 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 not even doing this like napkin maths.
Simon Eriksson at TurboPuffer talks about this napkin math word like you.
It's like, all right, here's the theoretical limitation of the hardware.
Read from SSD might be, I don't know, 30 microseconds.
And then like, how can I build a system that is as close to this as possible, as opposed to the other way around saying, okay, like, you know, a human will notice like 20 milliseconds, like 100 milliseconds.
Let's build around that.
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 with the storage system layer, you know, I know Simon working on Turbo Puffer, they're doing great stuff over there.
You have to think about the machine scale.
and the machine speed, which is a lot faster than human perception.
Like a human can tolerate maybe 100 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.
Simon says, 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, um, pack of data across the globe is sending into space.
Is it because the speed of light is faster in vacuum?
Quite a bit faster.
Or, well, it's not fuel vacuum.
No way.
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.
Possible.
But now, if we're talking about 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?
Yeah, yeah.
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.
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 going to get into because, again, that, but like.
Yeah, so 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 into 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 a...
Maybe they're doing that.
I don't know.
Maybe they're doing that.
Yeah.
But, I mean, the thing 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.
in terms of performance.
The rabbit hole just goes so deep there.
You're almost certainly running on multithreaded systems, right?
And you're like, oh, I need to have a multithreaded program.
I need to have synchronization in there.
Well, you get the best performance if you 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, like, kind of...
setup of caches above the cpu like you can think of registers as a cache and you have l1 l2 l3 even your memory and onto 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 and 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 dumb 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.
You 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're just like sorting algorithms, they're just kind of awesome.
You could probably explain, you know, insertion sort and, you know, to kind of every...
Could you explain quicksort as well?
Quicksort's a little bit harder.
Right, that's the thing.
Yeah.
No, 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 many CS college students implement.
And he came to me, he's like, I think we could do better because, you know, there's actually a cache problem here.
Every time every node you're traversing down, you're going to a different cache line.
And he was thinking about using something else, a skip list to do this, which that's another awesome data structure everybody should kind of look at.
But at some point I was like, actually, this feels more like a B-tree.
So I implemented B-trees a couple of times before and figured out, like, how to implement a B-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 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.
for like eight items.
Just 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 that, I'm like, well, if I want to store more in 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.
And 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 a 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.
Like 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 can someone sitting outside of, you know, I'm not involved in how some of these libraries are or data structures are built.
I always thought, I think 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...
faster sorting thing like it's surely it is the fastest but if you could bring us a little bit of like how like you've been inside how it actually how it happens and how other people like yourself and and your colleague can say like oh what what if we what if we try something else yeah yeah so i mean my recollection here is he was working on this kind of the big um 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 and They were storing, you know, all like the map from user ID and email to whatnot 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.
At 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.
And if something just doesn't add up, like suddenly like, oh, there's this big explosion of 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 early on, I think part of one of the things was it was like a map from integer ID to something else.
And like if you look at red black tree, every node, you have your kind of value that you're storing the map and then you have two pointers.
You might have an energy ID that's like four ray pipes and then two.
Yeah.
And you look at that and you're like, oh, that seems like a lot of overhead.
And you could use a bit.
Well, the bee 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.
Well, that came later.
Yeah.
It came a lot later.
Can we talk about that?
Yeah.
I just want these other things, you know, I pay attention to like, you know, when there's research papers coming out about new data structures and like hash tables, hash tables are like the, the, one of the earliest things you've learned about in college and data structures.
Like how do I map keys to values where the ordering is unimportant?
That's when the hash tables come in and there is like, you know, the, the very earliest ways to do this.
I've implemented hash tables multiple times.
It's like.
You take your key, and it might be a string, and 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 linked list.
You have a linked list.
Yeah, this is a naive implementation, right?
Naive implementation, used quite frequently.
And over time, people discovered a lot better ways to do hash tables.
That's called chaining of your hash.
There's another technique called open addressing, where instead of actually having a linked list, you just...
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.
It came out of some folks at Google.
I believe it came out of their Swiss office because it was called Swiss Tables.
I believe that's where the naming came from.
I'm 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.
And 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 it.
It's 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.
to India, to Bangalore.
And so I was on a long flight.
No, it always starts like this.
And I'm 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.
got 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 folks were like, well, you know, we don't quite know all the details.
You're going to have to navigate this and that.
And there were some ideas there that combined them together and got to the point where it had kind of a complete implementation that was faster on most benchmarks, not quite all of them, but most of them.
And then the Go folks eventually picked this up and pushed it over the finish line.
And then so you, you know, like you came with the idea, you You 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, 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 runtime is a whole other level.
But then you just showed like, here's this implementation.
And then they kind of took the inspiration and the ideas.
Yeah, they're like.
this is great.
We want to make all...
They always are looking for ways to make it runtime faster, and there's like, you know...
Oh wait, and then so you did this in this contribution, this was a lot of years after you left Google, right?
Yeah, yeah.
This was from the outside.
This is from the outside.
That's 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.
You know, Intel published some papers about here's how to do the CRC and assembly very fast and contributed one of the implementations.
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 GoTracker with different people contributing to the work and then the Go team pushing all of this over the finish line.
This is where I need to mention our season sponsor 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 the 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.
Even 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 engineer in 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 producers, and join the review.
We've gone from single-player work to multiplayer engineering work with agents.
Oh, 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 set limits, track usage, so you can use capable agents without having costs balloon out of control.
Hop on board at linear.app.pragmatic.
Peter also previously mentioned Gaia, Google's internal system that mapped 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.
This brings us to our seasoned 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, role-based access control, basically everything a big customer security team asks for, delivered as a handful of clean APIs.
It's how companies go from, we have a login, to, we can sell to a Fortune 500 without standing up their own internal identity platform.
And WorkOS 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 permissions 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 routes it 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.
You were 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.
Yeah, yeah.
Now it's still here.
Seems like Google's early.
Yeah, yeah.
And, you know, I think that was a technology before its time.
I don't think it was ready to do at that point.
It looks like 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 a strange thing to say, but, you know, some other people feel it as well.
I 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, what's the company name?
The company that we founded is called Viewfinder.
Viewfinder, yeah.
It was in the mobile photo sharing space, which sounds familiar.
This is like Instagram.
This is like Snapchat.
This was in 2012.
Yeah.
Right as Instagram and all of them were 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 attract the users, how to get viral growth kind of thing.
Because from the outside, like what I read when I checked, you know, the story, just like, oh, you know, like you co-founded a startup.
It got acquired by Square.
Hooray.
like it sounds like you had bigger ambitions and this was a decent outcome but not the the dream right yeah yeah no it wasn't dream at all so uh the term i used was aqua hired so sometimes a company will get acquired get bought for you know 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 but it was it was not they were okay essentially they got their money back which is like As a founder, 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 getting them paid back kind of makes you feel a little bit better.
Yeah.
And then you spent a little time at the company that acquired you were just square.
Yeah.
And then you started itching a little bit again.
Yeah.
Yeah.
Because we've been working on these distributed file systems and storage systems.
Colossus, one of the kind of sister projects to Colossus is Spanner.
And how 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.
Right, right.
So what's the difference?
Yeah.
So for Colossus, you know, it was targeting large files, large append-only files.
You can't update them.
Append-only, yeah.
Yeah.
large 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 or like the relational data, you might have a table, you know, billions or 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 you know make the files mutable in your database and this is where like you know log structured merge trees you know come into play and they weren't invented at Google, but Google really popularized them with LevelDB, 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 at 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, there was actually three of us uh we were all at square and one of them is spencer and i mentioned earlier he was working on the gimp he's my college roommate and uh he was also google he was also google um this other guy ben darnell who was also at google he joined us um viewfinder ended up at square we you know like we're kind of just noodling on a project to do and we we'd actually had this design back in um viewfinder we're like ah we didn't we looked around for data space 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 and you know like hbase 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 um cockroach 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 we should just pivoted away from doing the mobile 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 managers convinced some of the management that like hey you can just work on this part-time you know to see if it had life behind the the design and then kind of conscripted uh ben and i into it and eventually 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 You 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.
And, you know, in hindsight, I wouldn't recommend that.
You wouldn't recommend?
Yeah, I wouldn't recommend taking the VC money.
Because 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 Sherpas people, you know, I've ever met.
And so you kind of have like an extra like, like.
person helping you on the team pretty much 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 a founder especially the technical founder right that you're focused on the engineering part yeah yeah no we actually took money right away for cockroach labs um it was almost like as soon as we left we got did a little road show you know kind of in the the bay area and got some interest and you know got an investor right away i have to ask about the name though Yeah.
How did the name of cockroach?
Yeah.
So, you know, we named the GIMP.
Yes.
That was, uh, that was mine.
Pulp Fiction had come out in college and like, oh, which we named this thing.
Oh, the GNU 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 were newly on the, this new database and you kind of want to give things a name.
um you can't just say oh we're working on this distributed database you kind of need something and this master was like oh cockroach db like cockroaches are unkillable i want these things this database to be unkillable you know cockroach is going to survive the nuclear apocalypse apocalypse so that was where the genesis was and just stuck yeah we're whenever a bunch of our nodes goes down this thing will still be up yeah yeah and you know this is where we're at today with cockroach db it's like one of the things that i point out on like holy crap, this is awesome.
You kill a node.
We did this whole campaign last year, which was really just to prove out something that had 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 in data centers and all the other data systems go down and Cockroach TV keeps on going.
I'm like, that's awesome.
When you started out, who were companies, startups that who 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 know, 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 point did you see that 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 are growing?
Like I'm...
I'm trying to get a sense of at what point did companies tell themselves, we need something distributed.
Yeah, 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 company, you know, like we'll sometimes be trying to knock them up.
But also they will call us, you know, and being like, there is a very big bank.
who'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.
After that, which probably knocked down, I'm assuming a region or database or a networking cable or a tree fell on something.
I think it knocked down a whole region.
You know, it was a region-wide power out.
It knocked down the region.
And there's a mandate from the CEO.
It's like, no, we just have to be able to survive these things.
And that gets pushed down all the way.
And you see this in other places where, you know, one of our early customers, they were running on AWS and they just got to the maximum size you can run in Aurora instance on.
And then.
what would typically happen at that point is then you have to shard your database you know this is very standard practice you you take your single node database you create 10 or 20 or 100 shards 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 the application developer is becoming 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 Can we talk about automatic sharding?
I think it's safe to some, most of us will know what sharding is when you're, but actually let's start from like manual sharding and then how you can implement automatic sharding.
And if you can tell us like, you know, tactics that a database like CockroachDB 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 know, you have a fixed number of shards, like.
Let's say it's just a hundred shards.
Your data model is a user with a lot of data associated with the user.
You just take the user and you say like, oh, they map into 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 re-shard.
And that's a very, very onerous process.
And re-sharding, 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...
it 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 rejave 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 so 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 various 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 fascinating how they all work.
But in consistent hashing, you can add an additional node, and then it only moves a fraction of the data from each shard over there.
There's various systems to do that, and I believe this is like When Her Lies Cassandra.
The way CockroachDB 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 and this is always true in any system that you can imagine them just in 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 you what i just described there actually sounds a lot like a b tree so there's this index on top that is like that 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 b tree you know you kind of squint you know it's like i think you squint and everything's either a b tree or it's a hash table and you 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 Btrees, 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 Btrees again and again.
And the other place 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 Btree.
I just kind of squint sometimes and I see like, actually kind of a btree 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 btree 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 btree index and they are ubiquitous in databases there's actually a paper called the ubiquitous btree 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're the foundations of single-node databases, and pretty much every data system I've worked on has had B-trees at some point in place in 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?
And why is 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 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 data to the database, it has to be durably written.
So if anything crashes, it comes back.
The 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 and 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, you know, kind of muddled.
The isolation is referring to isolation between transactions.
I 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.
The 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.
you'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, it's 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 you know track of your bank account or you know what's in your shopping cart or you know it's kind of like the the use cases are endless there and you do this wrong and you have very egregious bugs but now going back to weak consistency and strong consistency.
Anything less than luminarizability 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 results 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 Oftentimes when you're doing- The easiest thing is your credit card balance, right?
Yeah, yeah.
Yeah.
And 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 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.
That's eventual consistency.
Yeah, that's eventual consistency.
And you can often work around this, but just like- puts bigger burden on the application developer 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.
Is 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, Cockroach TV?
Well, we are writing all the replicas.
Well, yeah.
Yeah.
You're just doing it fast.
You're just doing it fast.
You're 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...
Do things that make it easier to write the applications, but do it in a very high performance way.
And we've gotten, you know, very, very good at this 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 would I enter the industry?
Like 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 astounding like how much sophistication has gotten into every area of computer science wherever you look at it.
One more thing on CockroachDB I want to ask about is RAF consensus.
What is the RAF consensus?
Yeah, I mean consensus protocols, the original consensus protocol is called Paxos and it was famously hard to implement.
Raft 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 do you typically agree on?
Yeah, yeah.
So you agree that the write occurred.
So like the way to think about consensus.
So you might think I want to replicate data and I write it to a primary and write it to a secondary.
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.
you 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 a multiple of them but if there's a crash i have to do recovery then i'm reading oh, I can read from 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 CockroachDB, how many replicas do you choose for either consensus?
It's typically three.
For some system tables, it can be five, and then...
Customers 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, you know, about the data durability, you might use five.
But there's a slowdown.
You know, the more you're writing to, it's like the more storage space.
And obviously, like we're talking like 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.
tens 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 in 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 latencies 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 a 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 mission critical?
Probably not.
Yeah.
So mission critical to my mind is like these kind of the other term of art is tier zero applications.
The ones that are like just the core crown jewels of what's running a company, you know, like a trading system, you know, your trading system can't go down.
If the trading system goes down, this is kind of a critical problem for the firm that is running the trading system, you know, banking systems.
But also, you know, like we work with DoorDash, you know, like some people might think that delivering your burrito is a kind of a mission critical system.
It certainly is for DoorDash.
right you know if that goes down it's problematic we power shopping carts um 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 criticality you think about yeah i guess of course that they're losing but but this is like when yeah 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 breaks right your water electricity is out you'll survive but It's not what you expected.
Yeah, yeah, yeah.
And everybody's like, what?
What age are we living in?
The electricity goes out.
We were kind of had 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 mission critical, except, oh, wait, every single search is ad 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.
I 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 mission 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.
I emailed.
And 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 there.
Like I didn't like bother setting up a secondary communication line.
So 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?
We 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 clear as engineering managers, those are engineers as well.
And then, you know, like we've been growing steadily.
It takes quite a while to build a distributed database.
not for the faint of heart so it took a couple years a couple times yeah uh yeah well i did distribute storage system i did a distributed 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 kind 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 within enterprises.
Our revenue has been, you know, kind of steadily growing over the years.
And, you know, it's at this place now where we see a path to future success as well.
And I want to ask 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, I was kind of, we were all technical co-founders.
Ben Spencer and I.
And we were already on a lot of code, and there was no exception.
But, you know, if, like, I look back at my GitHub output, you know, it's like kind of peak years, maybe 100,000 lines of code in a year.
In a year?
Which is a lot.
Yeah.
Yeah.
No, so, I mean, rule of rule.
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 RoxDB, which is an LSM.
At some point, I think it was back in 2019, you ran into limitations with it.
i decide um we want to rewrite it and did a big push to you know right that might have been like 40 50 000 lines of code and then a bunch of other people come up and helped and like you kind of look at that output i'm just like oh my goodness that was a lot to keep in your head a lot it's a lot just to type you know 100 000 lines of code the average kind of like uh that the industry talks about is 3 000 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 I 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, sometime 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 got to manage your team.
And we had a VP of engineering, but I was kind of getting to the point of like, okay, is my, are my coding days done?
You know, like kind of 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.
I 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, the core business, you know, I would get in there and do some work, but like, it's really hard.
that if you're in meetings all day, to also 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, 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, the org, the 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.
So how, when did you get, when did you start using AI?
When did you start to find it useful 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 about the GitHub Copilot, the cursor, the early version.
Yeah, GitHub Copilot.
That was the one I had the first exposure to.
We dabbled 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 it and I'm like, wait, kind of got that right.
This is crazy.
right 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 if you don't know how to be a good engineer it's like really hard to manage other i feel like you'll have a hard time i'm like just 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 going to 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 started 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 the, just this cadence of continuing improvements.
And.
You know, I was starting to do a lot with Sonnet.
and then starting to use opus and you know i had that same movement everybody else did and this was last year last uh november november december winter break right yeah it was thanksgiving i distinctly remember it because you know you were not chilling you were coding you were agenting i was uh agenting just like everyone else yeah i had this thing i'd wanted to do for a long period of time um on cockroach tv which is like I wanted to like test like all these configurations of Cockerish DB across like, you know, different vertical scaling, like how many CPUs you have on a node, how many stores, you discs 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 I couldn't ever quite get prioritized appropriately because it never seemed like kind of critical, but I've like, I always had this intuition there was something there.
And then over this like four day span, the code just like materialized as I was using.
I think that was Opus 4-7 or 4-5, whatever the number was.
Like the recollection I had is, you know, like 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.
If you've ever seen like some of those, you know, a movie where they have this kind of archetype of a...
software engineer gets in front of the keyboard and they start typing, show the screen.
It's just like, it's going way beyond human speed.
And then it was, it was gone that right.
Like it wasn't, I think the software engineers, like we used to laugh at these, like, I still remember swordfish, the thing when they're visualizing the things are going or the code appearing, you know, you're seeing that the person's typing and then it's a big line and a software engineer is like, we're laughing cause it's not how it is, but, but it's crazy that like that effect, right?
Yeah.
But now it is.
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 on 10,000 lines.
It's like a crazy amount.
You physically cannot type that fast.
you 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 well it started with this tool um that was like this kind of benchmarking tool that tested this matrix i am the cto we have an office of the cto um 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 CockroachDB 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 good at 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.
But more like, hey, we have this problem.
Talk through it.
Be a partner with me.
And be a sparring partner.
Be a 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.
Rubber duck.
Rubber duck it.
I think I've heard it as yellow duck, you know.
Just go talk to something.
You don't even need it to respond.
Now you can talk to this system, this intelligence, and it will give you back stuff.
And it's not always right.
I mean, this is the thing even today.
These models are fantastic.
Fable's fantastic.
Astra's fantastic.
And they're not always right, but they kind of like, they know so much.
It's just encyclopedic.
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 on, you're right to push the back on that.
That's a new episode to write.
Yeah.
And yet like just able to make such fast progress.
And 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 company's gone on board with this now, where I think it's like probably 100% of engineers are using it to a greater or lesser degree.
and a lot of code is being produced.
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 advantage 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 at every line of code.
but 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.
The reason being, 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, a 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...
like naive way of management where like, you know, they don't push back.
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 so much more involved.
Like I think this is a 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 do agree.
I use the engineering manager shorthand, but it's really about being a tech lead for like a 30 or 40 person organization.
you know, or being an architect for what I think that the term architect gives me a little bit of a distaste, but it's being an architect.
He's also on the ground, a hands-on architect, hands-on architect, and you don't have any of the 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.
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.
Higher 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 CockroachDB, 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.
It's here to say.
I think that's for sure.
Yeah, I mean, like, you know, one of our theses, which is not crazy.
every 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.
We will see that continue 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 mini 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.
500 applications, a thousand applications.
By non-engineers.
By non-engineers, primarily by 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 your CFOs all over the place and ours is no exception.
Producing dashboards that they can 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.
helped 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 gained 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 kind of terminal do you use?
Yeah, yeah.
It's evolved over time.
know like when i first started dabbling the ai stuff again it was you know github copilot was an emacs user for like 20 something years i got convinced to move to vs code but that's all gone now um 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 uh i use 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 desktop 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 that.
Sometimes it's Astra, sometimes it's the other ones.
But you like you have one producer design, you have the other one being like, hey, my colleague produced this.
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.
We'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.
Should I use Sonnet?
Should I use Opus?
Should I use Fable?
Should I use Sol or Astra?
And I think, you know, maybe if you, like, I really need the speed.
I 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 like kind of cognitive overhead is about five to 10 sessions concurrently, but sometimes those sessions will have many sub-agents doing things.
Yeah.
And they'll be long running.
Yeah.
It'll depend on what I'm doing.
So.
As 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.
Anthropic has dynamic workflows.
I can't remember what the codex thing is called, but they have various ways of spinning up graphs of agents and prosecuting them.
I think sometimes I'm probably using 100 sub-agents.
Others, it's only like five.
It depends on what's happening.
Sometimes I'm not doing any of that agentic stuff because I'm often thinking about something else.
Since you were an Emacs user for 20 years, you know, using the terminal, right?
Well, Emacs, but how come you moved to graphical interface with agents?
A lot of people still use terminal UIs.
Yeah, yeah.
Well, 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 was just more seamless.
And like Emacs keeps on catching up.
It always feels a little bit...
you 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 in tabs, you know, have like eight of them open.
And then they started taking over.
It used to be like just cloud code in the terminals.
Yeah.
And then, 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 was 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 I'm down the side, you know, and it's like, they're kind of like tabs in some regard and shit.
But the whole integration that Anthropic has been doing in OpenAI is doing the same thing now.
By the way, like I'm not dissing cursor and factory and cognition.
They're all pushing the same thing.
It's.
incredible 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 the quality has to be higher.
Security has to be higher.
I'm glad you mentioned quality.
Can we talk about that?
Cause I'm seeing across the industry just.
quality declines which you cannot fully put your finger on ai but oftentimes it is people pushing up more and more and just not paying attention to just small regressions here and there again like you're you're building a database like yeah have you noticed any or have you gotten feedback of any quality regressions or 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 an observed 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 a thing that i i hope the the model providers are listening to but you you need to give them quite a third 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 So getting the humans to actually be very disciplined about their testing is also challenging.
And I think it's actually easier with the 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 you can use.
And humans have always been 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.
And 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?
And 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, added on the security side and on the quality side.
And then also just on the, when I say quality, it's not just bugs, but it's also like, you know, just little things 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 evolve is like, you know, designers using Figma.
Well, I think that should be a thing of the past right now.
Our designer.
just 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 like she owns, right?
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.
What about code review?
What's your take on code review?
I think it's starting to get a bit controversial.
Is it going to stay or not?
Because there's been a practice that's been around...
You worked at Google.
Google has been so big on code review.
As I understand, there are two code reviews, right?
The domain experts reviews it, and then there's a language expert reviews it.
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.
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 pull request from a junior engineer, you have to give it more scrutiny than if you get it from your most senior engineer.
And you ask any tech lead, any engineer manager, any software engineer, they'll say, yeah, yeah.
So the junior engineer or someone new to the code base, you just have to give more scrutiny.
And what I'm finding is the agents are getting better, you're having to give less and less scrutiny.
And yet you do have to give scrutiny to some things.
It's like I said, it's like the testing will be incomplete.
Maybe they didn't follow the security stuff.
Maybe there was a performance regression.
And I think it's like assuring there's kind of constraints on the system so it's hard for them to do the wrong thing.
I 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 the 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 we'll 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 what is in compression is compiled out.
Fable set up for me a little system where it actually looks at the decompiled code to verify like that there's only a few extra instructions put in place.
I 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.
For what, like 20 plus years, you were writing so much code.
Like I'm sure you were in the zone.
Do you remember being in the zone and just churning it out?
You wrote a lot of like production ready code.
Now that you're coding with AI.
you get into the zone yeah absolutely and how how is that zone is it the same is it different feels it definitely feels a little bit different it's maybe a little bit less intense but you're managing more things cognitively like can you describe me like 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 and I take multiple of these experiments and I fire 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, well, that doesn't sound right.
Hey, what about this?
Or do we do this 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 was a, you know.
If 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.
I'm like, oh, that one failed.
That's fine.
You know, you just got to let go.
And this, 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, you know, very quickly.
But I talk about this in a, I have a whole bunch of analogies about like the, let's talk about analogies.
What analogies do you have about, about using AI?
I mean, the one I was, you know, advocating for, I 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, like walking down the road and sometimes, you know, someone will pass you, they're running, they got an efficient gate and whatnot, but everyone's under their own locomotion.
And.
These agentic coding agents came and it was like a car pulled up next to you.
You get into the car, you don't know how to drive, you don't understand the controls, but you got to get in and you start, you might figure out 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 isn't, it 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.
If 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 10x 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 100x engineer.
Yeah.
And so you're saying that you are seeing some folks who maybe let's not use the 100x engineer, but like this, like.
F1 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 salt engineering basics and they picked up uh they leaned into using these tools or what are they like yeah yeah I mean there is uh quite a bit of a it feels like you know it's directional that they're good software engineering 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 And 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 Churny, Thibault 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 Thibault, who built it.
And now you're kind of seeing, oh, these people are building all these tools and innovating.
Like, yeah, they...
really good before.
Yeah.
Well, I mean, this is a, I mean, I have two other analogies to give you about like the, what it feels like an AI you've undoubtedly heard about the term pair programming and programming, you know, and the, the idea behind pair programming is it's good to just like, you know, have one keyboard, one monitor and two engineers at it, one of the keyboard and the other one sitting beside them kind of like looking over the shoulder and giving guidance.
And I think there was an aspect of that feeling where.
I actually got Chachapiti to do a little image of this where, you know, 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 were really strong before, are now massively amplified.
you seen all this mathematical stuff coming out like the crazy proofs well i don't understand it but i 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 uh advancements and you know terence tau he's like probably the most famous living mathematician you know super genius he actually posted this session there's this recent breakthrough i think it's called the jacobian conjecture I don't even know what it meant, but he posted this chat GPT session where he's interacting.
I think it was chat GPT.
And you can see him interacting with this intelligence.
And it was crazy because he's talking to it as a peer colleague.
It's responding.
And it honestly looks like I'd encourage everyone to go look this up.
It looks like, you know, almost a foreign language.
It's like his domain expertise is getting amplified by the system he's interacting with.
And 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.
And if you don't, you just get sparkable stuff that doesn't have anything there behind it.
You know, you would probably admit you don't know much about distributed databases.
If you're going to ask Fable or Astra, build me a distributed database like Cocker TV, you will get something out, but it'll kind of be ultimately hollow inside.
But if you're an expert in databases and you ask to build a distributed database and you can point out all the various things you have to know about a distributed database, here's what you have to worry about, the storage layer, the networking layer, here's the various data structures, runtime inside.
You can actually get something quite magical very, very rapidly out of it.
So what would your advice be for engineers with like mid-level to senior level who have been figuring out how to do coding to become strong engineers in this, I guess, 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, you know, throughout my career.
And now I've kind of stopped doing it, but it's like the reason why is going to become obvious, which is like, I would always look at other people's code.
So I was at, you know, Google early on.
You probably heard of Jeff Dean.
Jeff Dean was an amazing coder.
His colleague, Sanjay Gamalat, also just an incredible coder.
And, you know, I would be looking at their pull requests.
I'd be looking at their changes.
It wasn't called pull requests at Google.
There's a different name for it.
But I'd be looking at my...
CL, right?
Yeah, CL.
This is a P4.
It's 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, Sanjay's code is really always very elegant.
You know, Jeff's high performance.
How's he doing that?
You know, like, how's he going about it?
And it's almost just like you acquire it via osmosis.
But now what you can do is not just acquire it via osmosis, but you can literally 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 can just ask the AI to dissect what they've done.
and 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.
Like, I mean, fundamentally, to some degree, AI is a translation tool.
They translate it from whatever, you know, kind of language or understanding it's in.
and keep on interrogating it until it gets it you know 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 upfront which was very helpful and it would have taken me a lot longer time beforehand so i can use this But 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, yeah.
I think, you know, I would encourage everyone, you have to have a little curiosity, right?
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...
The main Google search engine worked.
I was fascinated by like how the internals of Bigtable worked, even though I wasn't directly working on a Bigtable.
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 to 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 it's done 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.
I 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 explaining 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 these tools all the time yourself and using it like you have to learn.
I feel like I've learned more in the past, probably even year than the previous five years combined.
It's weird.
Given your trajectory and given the environment you were working in, right?
I mean, like anybody'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 messages, the first thing you wrote to me and I asked you like, hey, you know how.
how 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.
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?
Hopefully one of many.
Yeah, yeah.
No, and I'm not the only one in Cockroach Labs.
We have other people doing this as well.
I find it very exciting, you know.
It'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 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.
You 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.
One reason I was excited to talk to Peter is because he's been a very high profile and productive engineer, 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.
One 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 switch 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 a bit of a full circle.
He 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.
And 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.
And I find it a valuable reminder that learning and building deep expertise in software engineering, this is very valuable.
And as closing, I appreciate it 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 notes for more of the pragmatic engineering deep dives on Google's engineering culture and on distributed systems.
If you liked this episode, please make sure you're subscribed in your podcast player and a special thank you if you leave a rating.
Thanks, and I'll see you in the next one.