• Uncategorised
  • 0

Is Protobuf efficient for smaller keys

You’re absolutely right to think that if keys are small and values are long, Protobuf’s advantage becomes less obvious β€” but it still helps in most cases.

Let’s break it down πŸ”:


Scenario

Imagine this JSON:

{
"a": "[email protected]",
"b": "Some very long description about the user which goes on and on and on...",
"c": "1234567890"
}

Here:

  • Keys (a, b, c) are tiny (just 1 character each)
  • Values are huge (like the long description)

Will Protobuf Help Here?

βœ… YES… But Not as Much as Before

πŸ‘‰ Protobuf mainly saves space on:

  • Keys (Field numbers instead of names)
  • Booleans and Numbers (using Varint)
  • Optional Fields (Protobuf skips null fields, unlike JSON)

How Will This Be Stored in Protobuf?

Protobuf Definition:

 User {
string a = 1;
string b = 2;
string c = 3;
}

Protobuf Encoded Data:

0A 11 6A 6F 68 6E 40 65 78 61 6D 70 6C 65 2E 63 6F 6D
12 3F 53 6F 6D 65 20 76 65 72 79 20 6C 6F 6E 67 20 64 ...
1A 0A 31 32 33 34 35 36 37 38 39 30

Size Comparison

FormatSizeWhy?
JSON132 bytesFull keys + values + quotes
Protobuf109 bytesOnly values + small headers
SavingsπŸ”₯ 17% smallerBut not 50% like earlier!

But Here’s the Secret 🀯

The real savings come when:

  1. You send thousands of messages πŸš€
  2. Your data contains repeated fields like lists/arrays
  3. You’re sending null or optional fields
  4. You use integers or booleans

Example:

{
"id": 123,
"name": "John Doe",
"isAdmin": false
}

βœ… JSON: 50 bytes
βœ… Protobuf: 7 bytes


What Protobuf Always Saves (No Matter What):

Data TypeJSON SizeProtobuf SizeSavings
Small Numbers"123" (5 bytes)7B (1 byte)80% smaller πŸ”₯πŸ”₯
Booleans"true" (4 bytes)01 (1 byte)75% smaller
Null Fields"email": null (13 bytes)(Skipped)100% smaller
Lists[1,2,3,4,5] (15 bytes)05 01 02 03 04 05 (6 bytes)60% smaller

When JSON Wins (Very Rare 🧐)

βœ… Only if:

  • You have tiny keys like "a"
  • All data is huge strings
  • No numbers, booleans, or lists
  • No optional fields

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *