---
title: "Protobuf"
description: "Protocol Buffers (Protobuf) is Google's language-neutral, binary serialization format that defines message structures in .proto schema files, compiled into strongly typed code for many programming languages, widely used in gRPC APIs and event streaming."
canonical: "https://motherduck.com/glossary/protobuf/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "Other Client APIs | MotherDuck Docs"
    url: "https://motherduck.com/docs/getting-started/interfaces/client-apis/other/"
  - title: "Kilo Code + MotherDuck Integration | DuckDB Analytics"
    url: "https://motherduck.com/ecosystem/kilo-code/"
gated_asset:
  title: "DuckLake on MotherDuck"
  url: "https://motherduck.com/product/ducklake/"
---

# Protobuf

> Protocol Buffers (Protobuf) is Google's language-neutral, binary serialization format that defines message structures in .proto schema files, compiled into strongly typed code for many programming languages, widely used in gRPC APIs and event streaming.

## Overview
Protocol Buffers, or Protobuf, is a serialization format developed by Google for compact, fast encoding of structured data. A message's fields and types are defined once in a `.proto` schema file, and the Protobuf compiler (`protoc`) generates typed classes or structs for that message in whichever language a service is written in — Python, Java, Go, C++, and many others.

## Why it's popular
Because messages are encoded as compact binary data using field numbers rather than field names, Protobuf messages are significantly smaller and faster to encode/decode than an equivalent JSON payload. This makes it a natural fit for gRPC, Google's RPC framework, where low-latency service-to-service communication matters, and for high-throughput event streaming pipelines built on Kafka.

## Protobuf vs. Avro vs. JSON
- **Protobuf** requires generated code from a compiled `.proto` schema, giving strong typing and small, fast messages, but making ad-hoc, schema-less reads harder.
- **Avro** embeds or references its schema at read time, so messages can be inspected and evolved more dynamically without regenerating code — a common reason Avro is preferred in some Kafka-based pipelines.
- **JSON** requires no schema or compiled code at all, at the cost of larger payloads and no built-in type enforcement.

## Where DuckDB fits
DuckDB doesn't decode Protobuf messages natively — there's no `read_protobuf()` function. Protobuf-encoded data (from gRPC services, Kafka topics using a Protobuf schema registry, or logs) is typically decoded upstream by an application, stream processor, or ETL tool, and landed as Parquet, JSON, or CSV before analytical querying. Once decoded and landed, that data is queried with DuckDB like any other file:

```sql
-- After a Protobuf → Parquet decoding step upstream
SELECT event_type, COUNT(*)
FROM read_parquet('s3://bucket/decoded-events/*.parquet')
GROUP BY ALL;
```