This is an engineering notebook published alongside an in-progress effort to add a Pebble (LSM-tree) storage backend to etcd , alongside the existing bbolt (B+ tree) backend.

The work itself lives in a development fork of etcd; the planning, research, and per-phase verification artifacts live in .planning/ inside that repo. This site is a public, lightly edited reflection of that material.

What you’ll find here

  • A motivation post explaining why anyone is doing this at all, and what is explicitly out of scope.
  • A series of journey posts — one per phase — written close to when each phase landed.
  • An architecture page with three reference diagrams: the interface seam, the snapshot wire format, and the durability protocol.
  • Status indicators on the home page showing how far the work has progressed.

Each post is short by design — under 1,000 words, written to be skimmable in a few minutes by an engineer who knows etcd or Kubernetes at the user level. The architecture page is the deeper reference.

What this is not

  • Not an official etcd or Pebble project communication. No relationship with either project’s maintainers other than the public issue tracker and code.
  • Not a recommendation. Until benchmark numbers and operator runbooks ship in Phase 7, there is no defensible “you should switch” story. Switching today is for people building their own opinion on their own hardware.
  • Not a tutorial. It is a notebook. It assumes you have read the etcd documentation and at least the README of Pebble .

Source material

Every claim on this site is grounded in either:

  • The etcd source tree at a specific commit (server/storage/backend/, server/etcdserver/, server/storage/wal/, server/storage/mvcc/).
  • The Pebble source tree at a pinned version (v2.1.5 at the time of writing).
  • Public GitHub issues with explicit numbers in the posts (cockroachdb#16624, cockroachdb#38322, bbolt#939, etcd#10321, etc.).
  • The roadmap and per-phase plans in the development repo’s .planning/ directory.

If anything here looks wrong, it almost certainly is — this notebook is being written while the work happens, and bugs in prose are at least as common as bugs in code.