Peter Mattis, co-founder and CTO of Cockroach Labs, recently sat down with Gergely Orosz on The Pragmatic Engineer podcast. The conversation covered the database fundamentals behind CockroachDB and how AI is changing the way our engineers build it. Here are the themes worth your time.
From GIMP to Gmail to CockroachDB: Peter Mattis on the Pragmatic Engineer Podcast
When Gergely Orosz sat down with Peter Mattis for The Pragmatic Engineer, the conversation started in a college dorm and ended with agents writing thousands of lines of Rust before lunch. In between, Peter walked through the systems, mistakes, and lucky breaks that shaped how CockroachDB is built.
A side project that taught him to keep going
Peter's first big project was GIMP, an image editor he built with his college roommate, an attempt at something like Photoshop. Neither of them knew how hard it would be, and Peter says that was the point. If you understand the full effort up front, you never start.
Weeks before their first release, someone posted on a Usenet graphics group about a program that did everything theirs did and more. They almost gave up. They shipped anyway, and the other project never surfaced again. His takeaway: "There's always going to be someone else working on your idea." It is a lesson he still repeats today, including about CockroachDB's competitors.
Saying no to Google, then building Gmail
That editor led to a call from Google when the company was three years old. Peter turned the interview down because he did not want the commute from San Francisco. A year later, he came back and joined on April 1, 2002.
His first assignment was the backend for an email project then known internally as Caribou: message threading, storage, and indexing. It launched as Gmail exactly two years after he arrived, and its storage offer looked so generous that many people assumed it was an April Fool's joke. Peter's part was the plumbing, and he remembers the B-trees in it. The ads that made the free model work, he says, came from a colleague who connected existing ad tech late one night. The invite system was a team idea, and it did two jobs at once: it limited load, and it made an invitation feel like a prize.
Colossus, and a design he is "proud and a little embarrassed" by
After Gmail, Peter helped found the team building Colossus, the successor to Google's file system. The old system topped out around a thousand machines, and Google wanted ten thousand. Colossus moved the file metadata into Bigtable, which created a circular problem, since Bigtable itself needed a file system underneath.
The fix was a bootstrapping layer: a small Bigtable that did not use Colossus, which let the real one start up. Peter's point was practical. Hacks can carry you a long way if you know they are hacks. Without that shortcut, he says, Colossus would have taken much longer to ship.
The team also used erasure coding, which splits data into chunks plus parity so a system can lose several copies and still rebuild everything. It provides stronger durability than three full copies, at lower storage cost.
Why a database is not just storage
The same experience pointed him toward databases. Colossus handled large, append-only files. Databases deal with small, typed rows and transactions. Spanner sat on top of that storage and inherited its constraints, which pushed designs toward immutable files and log-structured merge trees. Peter later helped build Pebble, the storage engine CockroachDB uses.
The idea for CockroachDB first appeared at his earlier startup, Viewfinder, a mobile photo-sharing company. The team looked for a database they liked, did not find one, and sketched their own, then shelved it because building a distributed database was not the job. When Viewfinder was acqui-hired by Square, the same problems showed up again, and this time the idea stuck.
Peter named the company. The cockroach, he explained, survives almost anything, and he wanted a database that was "unkillable."
What our name means in practice
Peter described how CockroachDB customers often arrive after a disaster. One large bank went through a serious regional outage and came away with a mandate from the top that critical systems must survive losing a region.
That led into the heart of the episode: why scaling a database is so hard to do by hand. Manual sharding turns an application developer into "a database developer," often without the time or tools to do it properly. CockroachDB treats data as one ordered key space, splits it into ranges, and moves those ranges as the cluster grows.
The same design supports strong consistency. Peter's example was a bank balance. With weak isolation, the same $100 can be spent twice. Serializable isolation makes concurrent transactions behave as if they ran one at a time, which keeps application code simple. Replication through Raft provides the safety net, and the cost is latency, since regional spread adds speed-of-light delay. His advice is to avoid chatty read-write patterns and to batch reads in parallel.
The B-tree that kept following him
Across all of this, one data structure kept showing up. Peter has built B-trees roughly a dozen times. He used one in Gmail's thread storage, then at Google he suggested one to replace the C++ STL map in a high-traffic internal system. It was faster and used less memory, thanks to better cache behavior and fewer pointers.
His rule of thumb makes it sound simple: "you squint and everything's either B tree or it's a hash table." Indexes are B-trees. The way CockroachDB maps key ranges to nodes looks a lot like one too.
Later, on a long flight to Bangalore, he started tinkering with Swiss tables, a newer hash table design, for Go's built-in map. Early benchmarks got faster, and the Go team eventually picked up the work and carried it over the finish line.
Stepping away from code, then coming back
At his peak, Peter wrote around 100,000 lines of code in a year. From roughly 2022 to 2024, he stepped back to run the company, and his output dropped. Meetings and coding do not mix well.
AI pulled him back in. He wanted his engineers to use the tools well, and he did not think he could guide them without using the tools himself. Over a four-day stretch last winter, he built a benchmarking tool he had long wanted and watched the code keep "materializing before my eyes." More recently, he built another B-tree, about 10,000 lines of optimized Rust, in roughly 30 minutes.
His day now looks different. He runs five to ten agent sessions at once, sometimes with many sub-agents each, and leans on a second model to review the first one's work adversarially on critical changes. He compares the feeling to running a swarm of research assistants who report back in minutes, not months.
What he learned about guiding the agents
Speed alone does not make good software, and Peter said so repeatedly. Agents can get "a little bit lazy on the testing side," so he gives them firm direction: property-based testing, metamorphic testing, deterministic simulation testing. He also runs an adversarial security review on every commit and sets guardrails, like automated checks on compiled output, to catch performance regressions.
He also thinks human code review will fade the way reading assembly did, once people trust the compiler. He does not claim that day has arrived.
His summary of the whole shift: "I think the ambition has to increase." More speed should raise the bar for quality, security, and performance.
Who gets the most out of it
Peter offered two analogies. In the first, a car pulls up next to you while you are walking. You can get in, but you have to learn to drive, and the best drivers right now are like F1 racers. In the second, domain experts are like sorcerers who know the right incantations. Ask a model to build a distributed database without that knowledge and you get something "hollow inside." Ask with deep expertise, and you can move very fast.
His advice to engineers followed from that. Use the AI as a tutor, and have it explain a senior engineer's code at any level you need. Stay curious about the systems next to yours, as he did with search and Bigtable while working on Gmail. Use the tools every day, because anyone teaching best practices is probably already out of date.
