FlatBuffers and FlexBuffers: From Bytes to Mutable Memory

This reading map preserves the complete first edition of FlatBuffers & FlexBuffers: From Bytes to Mutable Memory (18 September 2026), supplied for Reaktor's documentation on 4 October 2026. The cover describes a systems-programming book about memory layout, C++ implementation, protocol design, hardware-aware engineering, and a schemaless mutable-memory capstone: 30 chapters, 32 exercises, and C++20 source. Repeated running headers, footers, and printed pagination have been removed; the contents below link to every chapter and appendix across five part pages and seven reference pages.

Download the original 127-page PDF. The cover's complete untyped-vector example [1, 2, 3] is:

03 01 02 03 04 04 04 06 28 01

Parts and references

PageCoverage
Part I Bytes and OwnershipChapters 1–3
Part II FlatBuffersChapters 4–9
Part III FlexBuffersChapters 10–18
Part IV Quality and PerformanceChapters 19–23
Part V LiveFlex Mutable MemoryChapters 24–30
Appendix A Type Codes and Byte EquationsAppendix A
Appendix B Exercise Solutions and Implementation HintsAppendix B
Appendix C Reading the Official ImplementationAppendix C
Appendix D Checked FlexBuffers LaboratoryAppendix D
Appendix E Mutable Semantic LaboratoryAppendix E
Appendix F FlatBuffers Table LaboratoryAppendix F
Appendix G Sources and Edition NotesAppendix G

Complete contents

Preface: What this book will teach you

A serialization format is an agreement about bytes. A runtime data structure is an agreement about ownership, operations, and cost. They can share a representation, but they are not the same problem. This book follows that distinction all the way from a three-byte integer to the design of a mutable, schemaless memory engine.

The request that led to this book named “FlexBuffers” twice. This edition treats that as FlatBuffers and FlexBuffers, with the greater emphasis on FlexBuffers. FlatBuffers provides a particularly useful contrast: it makes many decisions at schema-compilation time that FlexBuffers has to represent in the data itself. Understanding both makes the design space much easier to see.

The goal is not to memorize an API. It is to become capable of looking at a buffer, reconstructing its meaning, implementing a reader and writer, identifying the invariants that make them safe, and deciding where the official representation is the right execution representation—and where it is not.

The source baseline

The implementation discussion is pinned to the Google FlatBuffers repository at commit b8431fbcd7a5c71817f314e18b332c0648554efa, dated 14 September 2026. The main source is include/flatbuffers/flexbuffers.h; the FlatBuffers chapters also inspect table.h and flatbuffer_builder.h. This is a source snapshot, not a claim that a particular release package contains every feature described. Public documentation and the source sometimes differ in emphasis. Where that matters, the book names the implementation behavior explicitly. [1–3]

Three kinds of material appear throughout the book. Wire-format facts describe what bytes mean. Implementation observations describe the pinned C++ source. Design proposals describe the new mutable engine developed here. The last category is deliberately not presented as an upstream feature or a measured performance result.

The companion and its limits

The accompanying C++20 project contains an original checked FlexBuffers reader, writer, verifier, constrained mutation functions, a small FlatBuffers table laboratory, and a mutable semantic laboratory. It has no dependency on the official FlatBuffers runtime. Its implementation is readable rather than micro-optimized. The complete core source is also included in the appendices.

The supplied test suite passed 20,220 assertions with GCC 14.2, and with Clang 17 using AddressSanitizer and UndefinedBehaviorSanitizer. It includes 2,000 generated documents, re-encoding checks, 30,000 bounded malformed/random-input probes, width boundaries, map ordering, mutation, and handle lifetime tests. A separate 25,000-run coverage-guided verifier fuzzing smoke test also completed without a reported sanitizer failure. These are actual executed checks; the receipts are in the companion.

The official C++ or Python runtime was not executed against this implementation during preparation of the book. Optional bidirectional C++ and one-way Python oracle programs are included, but neither was executed here. Self-round-trips and source inspection are useful evidence, not a substitute for independent interoperability testing. The code is an educational implementation, not a production-certified replacement.

The optimized capstone is a detailed architecture with executable foundations. The laboratory implements its semantic core using standard containers. Slab allocation, adaptive representations, SIMD hash probing, transactions, and concurrent snapshots are design work described in the book, not features secretly supplied by the laboratory.

How to read

Read Chapters 1–3 even when the vocabulary feels familiar. They establish the arithmetic and lifetime rules that keep the later code honest. Chapters 4–9 explain FlatBuffers. Chapters 10–18 build FlexBuffers from the trailer outward, then reconstruct the builder and verifier. Chapters 19–23 cover implementation quality, hardware, languages, and measurement. Chapters 24–30 develop the mutable capstone and its delivery plan.

At each byte example, pause before reading the explanation. Find the root. Identify the width that reads the current slot. Only then follow a reference and identify the width of the destination. Draw positions, not just values. Most difficult bugs in these formats arise because a correct number is measured from the wrong place.

The exercises are meant to be implemented. Their solutions are in Appendix B. The complete type table, equations, source-reading guide, and bibliography make the book usable as a desk reference after the first reading.

A promise about “maximum performance”

There is no data structure that simultaneously minimizes resident memory, update latency, lookup latency, snapshot cost, and implementation complexity for every workload. The capstone therefore specifies a workload envelope and makes its trade-offs visible. It aims at a strong performance frontier: very cheap scalar updates and typed scans, low-allocation container growth, fast repeated key lookup, stable logical handles, and standard FlexBuffers export.

A claim that it is faster than a particular alternative must come from the benchmark suite, not from the attractiveness of its diagram. The book gives you the machinery to make that claim responsibly.