Why Protocol Buffers Are Fundamentally Flawed: A Critical Analysis

Protocol Buffers (PB) is a widely used data‑serialization format that underpins many RPC frameworks, but the author, drawing on years of experience at Google, argues that its design is riddled with fundamental flaws.

Amateur origins and temporary nature – PB was created by hobbyists, leading to a brittle type system that feels especially hostile to both dynamic‑language users and static‑language enthusiasts.

Lack of composability – Features such as oneof , map<k,v> , and repeated fields are mutually exclusive or severely limited, forcing developers into work‑arounds and manual handling.

Problematic design choices – Scalar fields cannot be distinguished from default‑initialized values, making it impossible to tell whether a field was set. Message fields exhibit surprising mutation behavior, requiring verbose generated methods ( has_foo() , set_foo() ) that cannot be abstracted without macros, which Google discourages.

Backward‑compatibility myths – Although PB claims forward and backward compatibility, in practice unknown fields are rarely preserved across transformations, and the “preserve unknown fields” guarantee adds little real value.

Code‑base pollution – Because PB tries to serve both as a transport format and an in‑process data model, developers end up writing massive amounts of generated code, duplicating logic that could be expressed in a few lines of regular code, and spreading the flawed type system throughout the entire codebase.

In conclusion, the author recommends abandoning Protocol Buffers for new projects, especially when the scale does not match Google’s internal trade‑offs, and suggests using more robust, composable serialization solutions.