Protocol Buffers

Google's schema-first binary serialization format, and the thing this spoke has been describing around the edges since yaff arrived in June — that page called Protobuf an ecosystem twice and linked to nothing. The first-party documentation site (T1, protobuf.dev) fills that hole.

Protobuf's own one-line pitch is comparative: "Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data — think XML, but smaller, faster, and simpler," and elsewhere "like JSON, except it's smaller and faster, and it generates native language bindings." You write a .proto file describing message types, run protoc, and get generated classes in your language with typed accessors and serialization built in.

The compiler directly supports C++, C#, Java, Kotlin, Objective-C, PHP, Python and Ruby, with Dart and Go through plugins, plus third-party implementations beyond that. Rust appears in the site's tutorial set. One .proto compiled into Java can be written there and read by C++ without either side sharing code.

protoc is the archetype this spoke already named

schema-driven-codegen was written in July with protoc as its stated archetype and no page behind the name — openapi-generator supplied the evidence instead. Protobuf is now the archetype in its own right, and it is the older and narrower of the two: OpenAPI Generator emits 50+ clients and 40+ servers plus Postman collections and JMeter plans from one spec, while protoc emits message classes for ten languages and delegates everything else to plugins. The plugin boundary is the interesting part, because it is what lets grpc add service stubs to the same compiler without Protobuf itself knowing what an RPC is.

What it deliberately does not do

The docs are unusually direct about the limits, which is worth recording because most format documentation is not:

• Not for large data. The format is for "packets of typed, structured data that are up to a few megabytes in size." Past that, the docs tell you to use something else.
• Not for large float arrays. Scientific computing with big floating-point matrices is named as a poor fit.
• Not compressed. Messages are compact, not compressed; compression is your problem.
• Not self-describing. The wire bytes carry field numbers, never names or declared types, so the .proto is required to interpret them — see protobuf-wire-format.
• Not a standard. The docs name "situations requiring formal standards compliance" as a reason not to use it, and non-OOP languages (Fortran, IDL) as unsupported.

That last pair is the honest read on Protobuf's position: it is a vendor format with an open implementation and a very wide install base, not a standardised one. Set that beside openapi-generator's OpenAPI, which is a specification with a governing body, and the two archetypes of schema-driven-codegen differ on governance as sharply as they differ on scope.

Versions

proto2 and proto3 were syntax choices; Protobuf Editions replaced that fork with a per-feature model — see protobuf-editions. Edition 2024 is current.

Related

protobuf-wire-format · protobuf-editions · grpc · schema-driven-codegen · yaff · clickhouse-rowbinary · openapi-generator · google · developer-tooling · synthesis