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
| Page | Coverage |
|---|---|
| Part I Bytes and Ownership | Chapters 1–3 |
| Part II FlatBuffers | Chapters 4–9 |
| Part III FlexBuffers | Chapters 10–18 |
| Part IV Quality and Performance | Chapters 19–23 |
| Part V LiveFlex Mutable Memory | Chapters 24–30 |
| Appendix A Type Codes and Byte Equations | Appendix A |
| Appendix B Exercise Solutions and Implementation Hints | Appendix B |
| Appendix C Reading the Official Implementation | Appendix C |
| Appendix D Checked FlexBuffers Laboratory | Appendix D |
| Appendix E Mutable Semantic Laboratory | Appendix E |
| Appendix F FlatBuffers Table Laboratory | Appendix F |
| Appendix G Sources and Edition Notes | Appendix G |
Complete contents
- Preface: What this book will teach you
- Chapter 1: Two representations, two jobs
- Chapter 2: Bytes, alignment, integers, and floating point
- Chapter 3: A safe C++ vocabulary for byte formats
- Chapter 4: FlatBuffers: the root, the table, and the vtable
- Chapter 5: A complete 32-byte FlatBuffer
- Chapter 6: Structs, vectors, strings, unions, and framing
- Chapter 7: Reconstructing the FlatBuffers builder
- Chapter 8: Schema evolution, generated code, and reflection
- Chapter 9: FlatBuffers verification and the boundary of mutation
- Chapter 10: FlexBuffers starts at the end
- Chapter 11: Widths are a small layout solver
- Chapter 12: Keys, strings, and blobs are different objects
- Chapter 13: Every vector family, one at a time
- Chapter 14: A map is two coordinated vectors
- Chapter 15: Building a reader as a set of views
- Chapter 16: Building the writer from first principles
- Chapter 17: Mutation, sharing, and why one outlier matters
- Chapter 18: Verification is a small security boundary
- Chapter 19: What “close to official quality” actually requires
- Chapter 20: Hardware-aware optimization without unsafe shortcuts
- Chapter 21: What modern languages help with—and what they do not
- Chapter 22: Benchmark the workload, not the advertisement
- Chapter 23: Optimizations worth earning
- Chapter 24: Capstone: choose the compatibility contract first
- Chapter 25: The 16-byte cell and the 32-byte descriptor
- Chapter 26: Allocation, roots, reclamation, and compaction
- Chapter 27: Fast containers without a declared schema
- Chapter 28: Transactions, borrows, and concurrent snapshots
- Chapter 29: Freeze and thaw without changing the standard
- Chapter 30: Build the capstone in stages, then earn its speed
- Appendix A: Type codes and byte equations
- Appendix B: Exercise solutions and implementation hints
- Appendix C: Reading the official implementation
- Appendix D: Complete checked FlexBuffers laboratory
- Appendix E: Complete mutable semantic laboratory
- Appendix F: Complete FlatBuffers table laboratory
- Appendix G: Sources and edition notes
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.
Related Reaktor documentation
- FlexBuffers implementation: current code, ownership, and adoption.
- Performance and stability review: measured platforms, JSON, and Protobuf comparisons.
- Reaktor FFI: language boundaries, frames, and ownership.