OmniBuf

Benchmarks &
Format Comparisons.

Head-to-head throughput, wire size, and field lookup measurements comparing OmniBuf against Protobuf, FlatBuffers, Cap'n Proto, MessagePack, and JSON.

Benchmarks.

Measured on an 11-field telemetry message with nested structs and arrays. Shorter bars = Faster / Smaller.

Full Message Decode Speed
OmniBuf
145 ns
FlatBuffers
171 ns
Cap'n Proto
756 ns
Protobuf
976 ns
MessagePack
2500 ns
JSON
3893 ns
Full Message Encode Speed
OmniBuf
96 ns
FlatBuffers
559 ns
Protobuf
563 ns
Cap'n Proto
1034 ns
MessagePack
1586 ns
JSON
1702 ns
Read a Single Nested Field (peer.location.city)
Cap'n Proto (Unframed Shared Memory)
5 ns
FlatBuffers
13 ns
OmniBuf
78 ns
Cap'n Proto (Framed Packet)
227 ns
MessagePack
599 ns
Protobuf
964 ns
Packet Size on the Wire
Protobuf
341 B
OmniBuf
362 B
Cap'n Proto
560 B
FlatBuffers
600 B
OmniBuf (With Field #0 Names)
622 B
MessagePack
656 B
JSON
803 B

Integration Tiers & Opaque Splicing.

OmniBuf works directly on existing generated Go structs with zero codegen, or via the protoc-gen-omnibuf plugin for generated single-pass methods and lazy Opaque API wire splicing.

Protobuf vs. vtprotobuf vs. OmniBuf
Operation Protobuf vtprotobuf OmniBuf (No Plugin) OmniBuf (Plugin)
Marshal 562.6 ns (0 allocs) 127.7 ns (0 allocs) 200.3 ns (0 allocs) 99.1 ns (0 allocs)
Unmarshal (Safe) 976.4 ns (25 allocs) 555.5 ns (24 allocs) 778.1 ns (19 allocs) 494.4 ns (17 allocs)
Unmarshal (Zero-Copy) 976.4 ns (25 allocs) 201.3 ns (0 allocs, Pool) 303.7 ns (0 allocs) 198.3 ns (0 allocs)
Read 2 Nested Fields 978.0 ns (25 allocs) 202.0 ns (0 allocs, Pool) 303.7 ns (0 allocs) 128.1 ns (0 allocs, Opaque)
Read-Modify-Write 1,550.0 ns (25 allocs) 332.2 ns (0 allocs, Pool) 504.0 ns (0 allocs) 153.5 ns (0 allocs, Splice)
Why OmniBuf beats vtprotobuf with simpler generated code: For schemas/peer.proto, vtprotobuf emits 1,899 lines of unrolled per-byte LEB128 loops, SizeVT() passes, and backwards buffer indexing. By contrast, protoc-gen-omnibuf emits just 781 lines (including all three Opaque* lazy readers with full scalar splice support) that call standard AppendVarint / DecodeVarint helpers, yet runs 1.29x faster on Marshal and 2.16x faster on Read-Modify-Write because the wire format avoids 2-pass sizing and multi-branch varint loops.

How OmniBuf compares to other formats.

OmniBuf vs. Protobuf
OmniBuf Protobuf
WIRE SIZE ENCODE SPEED DECODE & SKIP MEMORY EFFICIENCY SIMPLICITY

OmniBuf stays within a few bytes of Protobuf while encoding up to 6x faster, decoding up to 8x faster, supporting raw message concatenation, and making every wire type inspectable without a schema.

Why Choose OmniBuf Over Protobuf
  • ✓ Over 2x to 6x faster encoding with single-pass writes instead of measuring nested objects twice.
  • ✓ Over 2x to 8x faster full decoding with branchless Prefix-Varints.
  • ✓ Self-describing 4-bit wire types and optional Field #0 names eliminate Wire Type 2 ambiguity.
  • ✓ Faster field skipping while preserving raw message concatenation (append(msgA, msgB...)).
When Protobuf Wins
  • → Built into existing Protobuf ecosystems and third-party services where you cannot change the wire format.
  • → Roughly 6% smaller wire payloads (341 B vs. 362 B in our benchmark) because Protobuf uses 3-bit tags and 1-byte lengths on small nested messages.
OmniBuf vs. FlatBuffers
OmniBuf FlatBuffers
WIRE SIZE ENCODE SPEED DECODE & SKIP MEMORY EFFICIENCY SIMPLICITY

OmniBuf is 40% smaller on the wire, over 6x faster to encode, and faster on full message decodes while using standard .proto schemas instead of bottom-up builders.

Why Choose OmniBuf Over FlatBuffers
  • ✓ 40% smaller packets on the wire because there are no VTables or alignment padding.
  • ✓ Over 6x faster encoding with normal top-down writes instead of bottom-up builders.
  • ✓ Faster full message decoding and supports raw byte concatenation.
  • ✓ Works directly with standard .proto schemas.
When FlatBuffers Wins
  • → Faster single-field random access when reading one field out of a very large message via VTable offsets.
OmniBuf vs. Cap'n Proto
OmniBuf Cap'n Proto
WIRE SIZE ENCODE SPEED DECODE & SKIP MEMORY EFFICIENCY SIMPLICITY

On framed network packets, OmniBuf is 36% smaller, 12x faster to encode, and over 6x faster to decode without multi-segment pointer bounds checking.

Why Choose OmniBuf Over Cap'n Proto
  • ✓ 36% smaller network packets without 64-bit pointer fat or 8-byte word padding.
  • ✓ 12x faster encoding with zero heap allocations.
  • ✓ Over 6x faster full decoding and nearly 3x faster single-field reads on framed network packets.
  • ✓ Uses standard .proto schemas and supports raw message concatenation.
When Cap'n Proto Wins
  • → Includes a built-in RPC system with promise pipelining (chaining dependent RPC calls in a single network round-trip).
  • → Fixed-offset struct layout allows jumping straight to fields in very large messages without scanning preceding field headers.
OmniBuf vs. MessagePack
OmniBuf MessagePack
WIRE SIZE ENCODE SPEED DECODE & SKIP MEMORY EFFICIENCY SIMPLICITY

OmniBuf is nearly half the size of MessagePack in shared-schema mode, and smaller even with Field #0 inline field names enabled while encoding over 6x faster.

Why Choose OmniBuf Over MessagePack
  • ✓ 45% smaller packets in standard .proto mode, and 5% smaller even with Field #0 inline names enabled (622 B vs. 656 B).
  • ✓ 16x faster encoding (or over 6x faster with Field #0 inline field names included).
  • ✓ Over 20x faster full decoding and over 8x faster single-field skipping.
  • ✓ Hoists nested child schemas into Field #0 once per message instead of repeating key strings inside every array element.
When MessagePack Wins
  • → Supports arbitrary schema-free maps with heterogeneous keys when no .proto structure exists.
OmniBuf vs. JSON
OmniBuf JSON
WIRE SIZE ENCODE SPEED DECODE & SKIP MEMORY EFFICIENCY SIMPLICITY

OmniBuf is less than half the size of JSON and 17x to 32x faster, while still letting you use official ProtoJSON for human-readable debugging from the same .proto file.

Why Choose OmniBuf Over JSON
  • ✓ 55% smaller on the wire (and 23% smaller even when Field #0 field names are embedded).
  • ✓ 17x faster encoding and 32x faster decoding.
  • ✓ 55x faster single-field extraction without parsing text brackets or quotes.
  • ✓ Compatible with official ProtoJSON so you can still accept or emit plain text JSON from the same .proto schema.
When JSON Wins
  • → Readable as plain text in browser devtools and curl when no decoder tool is available.
Benchmark Environment & Workload Details
Hardware & Runtime
CPU: Apple M1 Pro (darwin/arm64)
Compiler: Go 1.27.1
Command: just bench
All benchmarks serialize and deserialize an identical 11-field BGP/Telemetry PeerUpdate message containing unsigned and ZigZag-signed integers, booleans, IEEE-754 floats, string lists, packed integer arrays, a 6-field nested Location sub-message, and a 4-element repeated Neighbor sub-message list.