Peter Mattis on Distributed Databases and Coding with AI

Peter Mattis traces his interest in computers to games and the machines his family kept at home. He typed programs from books before studying mechanical engineering, then switched to computer science after finding its coursework more natural.

At college, Mattis and his roommate built the image editor GIMP and its graphics toolkit. They learned by trying things and consulting papers; he thinks a little naivety helped them start a project whose full difficulty they did not yet understand.

Shortly before they released GIMP, someone announced a similar program with even more features. They kept working anyway. Mattis says hearing that others have the same idea should not automatically stop a team from building and releasing its own work.

After college he moved from graphics toward storage and met Google founders Larry Page and Sergey Brin. He recalls turning down an early Google offer because of the commute from San Francisco, then joining after another startup did not work out.

At Google, Mattis worked on the backend of the email project that became Gmail, including threading, storage and indexing. He recalls the shock of launching with far more free storage than competing services offered at the time.

Gmail built on Google’s distributed file system and search expertise, but its prototype’s retrieval system was rewritten. Message threading needed lookups and indexes; Mattis remembers B-trees helping manage associated data such as unread counts.

He recalls Paul Buchheit incorporating advertising into Gmail, and the team using invitations to control a rollout when capacity was limited. These are his recollections of early product and infrastructure decisions, not a complete history of the service.

The conversation turns to Google’s shared infrastructure, including its monorepo and build tooling. Mattis later joined the team working on Colossus, the distributed storage system that succeeded the Google File System.

Colossus stores data across a fleet of machines. Mattis describes erasure coding as a way to tolerate failures with less storage overhead than keeping a full copy for every tolerated failure.

In the illustrative nine-chunk scheme, any five chunks can reconstruct the data, so four can be lost. The exact encoding and its deployment matter; the point is that redundancy need not mean duplicating an entire file several times.

Mattis says the earlier GFS master became a scaling bottleneck for metadata. Colossus used Bigtable for metadata such as file names and chunk lists, while regular Bigtable itself also needed storage.

The team addressed that bootstrapping circle with a foundational Bigtable that did not depend on Colossus, then put Colossus and ordinary Bigtable above it. He describes it as a practical way to get started that was later replaced.

High throughput, availability and low latency are distinct goals. Mattis notes that disk-backed storage can sustain large throughput while individual reads still incur substantial latency; faster SSDs and networks change the engineering tradeoffs.

He encourages engineers to reason from hardware limits rather than human-perceptible delay alone. Network distance, processor caches, synchronization and data locality all influence performance; avoiding unnecessary coordination can matter.

At Google a colleague noticed that an extensively used C++ map had substantial memory and cache overhead. Mattis built a B-tree-based alternative that packed more items into a node, improving locality for suitable uses.

A sorted array is efficient for a small group of keys. A B-tree extends that idea by splitting full nodes and indexing them through parent nodes. Mattis notes a tradeoff: shifting entries can mean losing the pointer stability offered by the original map.

The optimization began with observing an actual profile, not assuming that a standard library must already be optimal for every workload. Fewer pointers and better spatial locality helped the B-tree use less memory and run faster in that setting.

He also followed work on Swiss-table hash maps and experimented with an implementation in Go. Hash tables map keys to buckets; designs differ in how they handle collisions and arrange metadata for efficient access.

On a long flight he got some benchmarks to improve, then combined ideas from others and built a version his company could use. The Go team later took the work further for the runtime; Mattis credits the wider collaboration rather than claiming a solo change. The [Go team’s technical account](https://go.dev/blog/swisstable) explains the resulting map design.

After Colossus and other work at Google, Mattis co-founded Viewfinder, a mobile photo-sharing startup. He says the team struggled to find the right route to users and was ultimately acquired by Square primarily for its people.

He distinguishes a distributed file system such as Colossus, designed around large append-oriented files, from a database such as Spanner, which supports structured records and transactional access on top of storage.

Log-structured merge trees are one way to build a mutable database using immutable files. Mattis points to Pebble, an LSM-based storage engine he implemented for Cockroach Labs, as part of that engineering lineage.

While building Viewfinder, the founders had discussed a database resembling systems they knew at Google but set the idea aside. At Square they saw similar storage problems, worked on the idea and eventually spun it out as Cockroach Labs.

Customers often seek a distributed database after an outage or when a single-node system becomes difficult to scale. Mattis discusses the cost of manual sharding: application teams must track placement and rebalance data as demand grows.

A simple sharding scheme hashes each user to one of a fixed number of shards. When a shard fills up, moving and remapping data can become onerous; automatic range splitting and placement seek to move that operational work into the database.

An index maps key ranges to their locations. Mattis sees a family resemblance to B-trees, which also appear in ordered database indexes. The specific implementation still depends on the database and workload.

Transactions group changes so they can succeed or fail together. Isolation concerns how concurrent transactions interact; serializability gives results equivalent to some serial ordering, simplifying reasoning about certain application invariants.

With eventual consistency, a replica may temporarily return an older value after a write. Applications can accommodate that, but must account for it. Stronger guarantees can simplify application reasoning while introducing coordination costs.

Mattis introduces Raft as a consensus protocol used to coordinate replicas. Replication can protect data through failures, but availability, durability and latency depend on quorum rules and deployment configuration. The [Raft paper](https://raft.github.io/raft.pdf) describes replicated logs, majority agreement and safety.

He says three replicas are common in CockroachDB, with other configurations available. Cross-region placement can improve resilience to regional failures, but geographic round trips add latency; sequential reads and writes can compound that delay.

For Mattis, mission-critical means a service central to a business, such as banking, trading or a shopping cart. An outage can harm customers and reputation as well as revenue, so reliability requires sustained investment.

Mattis estimates that in his most prolific pre-AI years he wrote roughly 100,000 lines of code annually. This is his recollection, not a controlled measure of productivity or quality, and lines of code alone are a poor comparison across projects.

As his management responsibilities grew he spent less time coding. He later returned to hands-on work partly to understand and guide the company’s use of coding agents, finding that the tools changed how quickly he could explore.

He describes using a model as a discussion partner for technical ideas: it can surface possibilities quickly, but its answers can be wrong or overly agreeable. Domain knowledge remains necessary to challenge and test what it proposes.

Mattis compares directing agents to hands-on technical leadership: setting architecture and correcting work while several tasks proceed. Host Gergely Orosz notes that managing people includes relationships and responsibilities absent from this analogy.

He predicts that AI will write an increasing share of software and describes an internal platform where non-engineers made small applications. His forecast is a view of the future, not evidence that all software will follow that path.

His workflow uses multiple coding sessions and, for critical work, an alternative model to challenge a design. He reports handling roughly five to ten sessions concurrently, though the number of subordinate agents varies with the task.

He moved from Emacs to VS Code and more recently to desktop interfaces that make multiple agent sessions easier for him to follow. The choice reflects his own workflow and may change as the tools evolve.

Orosz asks whether faster output increases regressions. Mattis argues that agents need explicit direction to test thoroughly; he names property-based testing, metamorphic testing and deterministic simulation as techniques to apply where appropriate.

He also suggests using agents for adversarial security and performance review. These are proposed ways to widen scrutiny, not proof that automated reviewers catch every defect or replace expert judgment.

On code review, Mattis says he still looks at most agent-produced code but expects the level of line-by-line scrutiny to change. He stresses that incomplete tests, security details and performance-sensitive paths still need attention.

For one performance-sensitive change, he had an agent create a check on generated assembly so that future changes could detect unwanted overhead. This illustrates a specific guardrail; whether it works depends on what the check actually measures.

He describes his working rhythm as running several experiments, checking progress, redirecting approaches that look wrong and letting failed ideas go. The greater parallelism also increases the amount he must keep track of.

He likens learning agentic coding to learning to drive: skill with the controls and knowledge of failure modes matter. His discussion of highly amplified engineers is an analogy and observation, not a measured universal multiplier.

Mattis believes domain expertise helps people ask better questions and evaluate what models produce. He cautions that a superficially plausible database generated without understanding its storage and networking requirements may be hollow.

He recommends studying strong engineers’ code and using AI to explain unfamiliar pieces at different levels. Such explanations are a starting point for learning and should be checked against the code and other sources.

Curiosity should extend beyond one’s immediate assignment, he says: learning adjacent systems and business domains can lead from understanding an existing design to contributing improvements. He also acknowledges that the current pace is exciting and exhausting.