Protocol Buffers v36: The Serialization Format That Outgrew Its README

What Protobuf Actually Solves

Protocol Buffers solves a specific problem: you have structured data that must cross language boundaries, platform boundaries, or both, and you want a compact binary representation that does not tie you to a single programming language. The README defines it as a language-neutral, platform-neutral, extensible mechanism for serializing structured data. That definition is accurate but understated. The real value is the contract: you write a .proto schema once, and the protoc compiler generates code for C++, Java, Python, Objective-C, C#, Ruby, Go, PHP, Dart, and JavaScript. That list alone tells you who this is for. It is for teams that operate polyglot services, where a Python service must talk to a Go service and a C++ client, and where hand-rolled JSON schemas have become a maintenance burden. It is not for a solo developer who just needs to save a Python dict to disk. For that, the overhead of a schema compiler and a runtime is hard to justify.

The Two-Part Installation That Trips Everyone

The README is explicit: to install protobuf you need two things, the protocol compiler (protoc) and the runtime for your chosen language. That split is the first real friction point. For non-C++ users, the simplest path is a pre-built binary from the release page, packaged as protoc-$VERSION-$PLATFORM.zip. That zip contains protoc plus a set of standard .proto files. But the README warns that pre-built binaries are only provided for released versions. If you want HEAD, or you need to modify protobuf code, or you are using C++, you must build protoc from source. That is a significant barrier. The C++ build is not a single command; the README points to src/README.md for instructions, and the warning about building from main is blunt: your build will occasionally be broken by source-incompatible changes. This is a project that assumes you are either a consumer of stable releases or a contributor who accepts instability. There is no middle ground.

Bazel Is the Path of Least Resistance, With Caveats

The README devotes more space to Bazel than to any other build system, which tells you where Google's own usage sits. For Bazel 8 and later, Bzlmod is the recommended route. You add a single line to your MODULE.bazel file: bazel_dep(name = "protobuf", version = <VERSION>). You can optionally override the repo name for WORKSPACE compatibility. The legacy WORKSPACE path is still supported, but the README notes that with the 30.x release there are more load statements to set up rules_java and rules_python. That is a concrete maintenance cost: every new major version of protobuf can change the build wiring you have to copy into your own workspace. The Bzlmod path is cleaner, but it requires Bazel 8, which is a recent release. If your organization is still on Bazel 7 or earlier, you are stuck with the WORKSPACE path and its extra load statements. This is not a trivial detail. The build system integration is where protobuf adoption often stalls.

The Runtime Language Matrix Is Not Uniform

The README lists ten languages, but the support is not uniform. C++ includes both the runtime and protoc, which makes it the reference implementation. Go and JavaScript are hosted in separate repositories, protocolbuffers/protobuf-go and protocolbuffers/protobuf-javascript. Dart is also external, at dart-lang/protobuf. That split has practical consequences. If you use Go, you are not installing from this repository; you are depending on a separate project with its own release cycle. The README does not say that explicitly, but the table makes it clear. For a team evaluating protobuf, this means the version of protoc you install must be compatible with the runtime version in your language's repository. The README does not give a compatibility matrix; it points to the version support policy at protobuf.dev/version-support. That is a gap. You will need to check that page before you upgrade protoc, because a mismatch between protoc and the runtime can produce subtle bugs.

The Main Branch Warning Is a Feature, Not a Bug

The README has an unusual warning for an open source project: if you work from the head revision of main, your build will occasionally be broken by source-incompatible changes and insufficiently-tested behavior. That is honest, but it is also a signal about how the project is developed. Protobuf is not a project where you can live on main and expect stability. Even release branches can experience instability between release commits. The README's advice is to pin to a release commit on a release branch. That is a concrete operational rule. For an engineer evaluating protobuf, this means your dependency management must be precise. You cannot use a floating version like "latest" in your build. You must pin to a specific release. The recent releases, v36.0 and its release candidates, show a steady cadence, but the README's warning suggests that the project prioritizes forward progress over backward compatibility. That is a trade-off you need to accept before adopting it.

A Real Limitation: It Is the Wrong Tool for Simple Jobs

Protobuf's strength, its schema and code generation, becomes a liability in small projects. If you have a single service and a single language, the overhead of defining a .proto file, running protoc, and managing a generated code dependency is not worth it. JSON, or even a language's native serialization, will get you further with less ceremony. The README does not say this, but the structure of the project implies it. There is no quick start that avoids protoc; every path goes through the compiler. The README links to tutorials and examples, but those assume you are willing to learn a new workflow. Another limitation is the build system friction. The README's emphasis on Bazel means that if you are not using Bazel, you are on your own for integrating protoc into your build. CMake is not mentioned in the README. That is a gap for many C++ projects. The project's own documentation site, protobuf.dev, likely covers other build systems, but the README does not. That is a real barrier for teams that do not use Bazel.

The Alternative: JSON or a Language-Native Format

The most direct alternative to protobuf is JSON, especially for web services. JSON has no schema compiler, no code generation, and no separate runtime. You write a struct or a dict, serialize it, and send it. The difference in approach is fundamental. Protobuf encodes data in a compact binary format that requires both sides to know the schema in advance. JSON is self-describing; the field names are in the payload. That makes JSON easier to debug and more flexible for evolving schemas, at the cost of larger payloads and slower parsing. For internal service-to-service communication where payload size matters, protobuf wins. For public APIs or for teams that value debuggability over performance, JSON is often the better choice. There is also a middle ground: JSON with a schema validator like JSON Schema, which gives you validation without code generation. But that does not give you the compact binary encoding or the cross-language generated code that protobuf provides. The choice comes down to whether you need the schema to be enforced at compile time or you are willing to enforce it at runtime.

Maintenance and Upgrade Cost

The README gives a few clues about maintenance cost. The version support policy page is referenced, which implies that language libraries have finite support timeframes. That means you cannot assume an old protobuf version will keep working forever. You will need to track the support window for your language runtime. The build system changes are another cost. The README notes that with the 30.x release there are more load statements for rules_java and rules_python in the WORKSPACE path. That is a concrete example of how upgrading protobuf can break your build configuration. The license is listed as unknown in the repository metadata, but the README states Copyright 2008 Google LLC. That is not a license statement. You will need to check the LICENSE file in the repository to know the exact terms. The README does not mention the license, which is a gap for anyone evaluating this for commercial use. In practice, protobuf is under a BSD-style license, but you should verify that from the repository itself before relying on it.

Editorial conclusion

Adopt Protocol Buffers if you need a stable, cross-language schema for data exchange and you can tolerate the build-system complexity that comes with Bazel or source builds. Do not adopt it if you need a simple, dependency-free serialization library or if you only target one language, where JSON or a native format will serve you better. Before committing, verify your language runtime's support window on protobuf.dev/version-support, and test the Bzlmod path with Bazel 8, since the WORKSPACE path now requires extra load statements for rules_java and rules_python.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes