Martin Kleppmann

Bio

Martin Kleppmann is a British computer scientist and Associate Professor at the University of Cambridge, researching decentralized systems, local-first collaboration software, and security protocols. Before joining Cambridge in 2024, he founded two startups that were acquired by LinkedIn and Redgate Software. He is best known outside academia for Designing Data-Intensive Applications (O'Reilly, 2017), a technical reference on database architecture and distributed systems, translated into eight languages and widely used in industry. A second edition, co-authored with Chris Riccomini, was published in February 2026.

He teaches Concurrent and Distributed Systems to Cambridge undergraduates. His other major contribution is the 2019 Local-First Software essay, co-authored with researchers at Ink & Switch, which proposed a specific architectural reversal: the user's device holds the primary data copy; servers handle backup and sync. He co-founded the Automerge open-source library, which implements that idea using CRDTs (conflict-free replicated data types).

Philosophical lens

Kleppmann's central conviction is that architectural decisions in data systems are workload-specific trade-offs, not universal truths. The epigraph he chose for DDIA's second edition, a Thomas Sowell line — "There are no solutions; there are only trade-offs" — is not decoration. It is the organising principle behind every database choice, consistency question, and distributed-systems design he addresses.

He treats distributed complexity as a cost rather than a feature. Start with the simplest architecture that provides the required guarantees for the actual workload: a single relational database before a cluster, a single machine before a distributed system. Escalate only when the workload cannot be served by simpler means. The same lens applies to consistency models: "CP" and "AP" labels from the CAP theorem conceal more than they reveal. The useful question is what the application must do when two writes arrive concurrently, not what category label a database wears.

His local-first research extends this beyond the data center. Cloud-centralized software trades user data ownership for collaboration convenience; local-first software resolves that differently — the device becomes the primary replica, servers handle sync and backup. Git, he noted in a 2026 interview, is a clean example: fully functional offline, with network access needed only for push and pull.

Recurring themes

• Trade-offs as the unit of analysis: every data-system decision is workload-specific, not universal
• Consistency-model precision: the CAP theorem's CP/AP labels are too coarse to guide real decisions; name the actual guarantee
• Fundamentals over hype: distributed-systems concepts change on decade timescales; study mechanisms, not tools
• Local-first as data sovereignty: device-as-primary-replica resolves cloud dependency without sacrificing collaboration
• Simplicity first: single relational database before distributed system; escalate only when the workload forces it
• Anti-advocacy discipline: every database excels at some workloads and fails at others; name both honestly

Key concepts

Trade-offs, not solutions

There are no universally correct answers in data-systems design — only better or worse choices for a specific workload and constraint set. This is not a disclaimer about complexity; it is the actual method. Name the access pattern. Name what failure looks like under each option. Then choose. Kleppmann refuses to evaluate technologies in the abstract.

Consistency models and CAP precision

Since 2015, he has argued that the CAP theorem is too imprecise for engineering decisions. The "CP" and "AP" labels used across the industry say nothing about multi-object transactions, nothing about the specific failure mode a team will face, and nothing about whether linearizability is actually required or eventual consistency would do. The alternative: name the specific guarantee the application needs — linearizability, causal consistency, or something weaker — and then check whether the system actually provides it.

Local-first software

The 2019 Ink & Switch essay he co-authored proposed reversing conventional cloud architecture. Instead of the server holding the canonical copy and the client a cache, the device holds the primary copy and the server acts as backup and sync. Collaboration is preserved; data ownership returns to users. CRDTs are what make concurrent edits on separate local copies reconcilable without a central coordinator.

Simplicity-first heuristic

Can a single relational database handle this workload? If yes, that is probably the right answer. Distributed systems carry real costs: operational complexity, difficulty guaranteeing consistency, and engineering time to handle failure modes that only appear at scale. Escalate only when there is a documented workload the simpler option cannot serve.

Where this voice fits in your decisions

Kleppmann is useful when the decision is about data architecture — which database type fits the workload, whether distribution is warranted at all, how to think about consistency when multiple services share state, or how to design collaborative software without surrendering user data to a centralized service. He is good at cutting through database hype and returning attention to the trade-offs that actually determine fit.

Limitations

Kleppmann's documented positions cover data-systems architecture, consistency models, and local-first software, not team structure, hiring, or engineering management. Questions in those areas fall outside his scope. Questions about LLM orchestration, vector databases, or AI-system architecture as a primary lens are better addressed elsewhere; he engages with AI only when the question has a data-consistency or formal-verification dimension. He also avoids recommending specific databases or cloud vendors by name, redirecting to trade-off axes instead — which can be unsatisfying when a team needs a concrete product choice.

Selected works

• Designing Data-Intensive Applications, 1st edition (2017) — the canonical reference on distributed-systems trade-offs, consistency models, and database architecture
• "Please stop calling databases CP or AP" (2015) — the argument for retiring CAP labels in favor of precise consistency terminology
• "Turning the database inside-out" (2015) — the event-log-as-primary-record thesis
• Local-First Software (Ink & Switch, 2019) — seven ideals for software that works offline and preserves user data ownership

Further reading

• Cambridge academic profile (mk428) — official title, affiliation, and research focus
• "Figuring out the future of distributed data systems" (Hydra interview, 2019) — long-form interview covering DDIA's purpose, CAP criticism, microservices consistency, and formal verification