gRPC vs REST vs GraphQL on the Wire

---
title: "gRPC vs REST vs GraphQL on the Wire: Benchmarks That Actually Matter at Scale"
published: true
description: "Wire-level data on Protobuf vs JSON payload sizes, HTTP/2 multiplexing, and GraphQL overfetch costs — the tradeoffs that drive protocol decisions for 10k+ concurrent mobile clients."
tags: api, mobile, architecture, performance
canonical_url: https://mvpfactory.co/blog/grpc-vs-rest-vs-graphql-wire-benchmarks
---

What You Will Learn

By the end of this article, you will have concrete wire-level data on gRPC, REST, and GraphQL — payload sizes, latency profiles under concurrency, and a decision matrix you can drop directly into your next architecture discussion. If you are designing a mobile-first backend serving 10k+ concurrent clients, this is the analysis that informs your protocol choice before it becomes a production constraint.

Prerequisites

• Familiarity with REST APIs and HTTP basics
• Basic understanding of mobile backend architecture
• Some exposure to gRPC or GraphQL is helpful but not required

---

Step 1: Stop Benchmarking on Localhost

Most teams benchmark protocols on localhost, then ship into a mobile-first environment with heterogeneous networks, variable latency, and 10,000+ concurrent clients. The results rarely match. The gap almost always lives at the transport layer.

Let me show you a pattern I use in every project: measure wire bytes and p95/p99 latency under concurrent load, not response time on a single thread.

---

Step 2: Payload Encoding — Protobuf vs JSON

For a typical API response, Protobuf binary encoding consistently beats JSON by a wide margin:

Payload Type	JSON (bytes)	Protobuf (bytes)	Reduction
Small object (5 fields)	210	68	~68%
Medium object (15 fields)	820	290	~65%
List of 100 objects	48,000	16,800	~65%
Nested object graph	3,200	1,050	~67%

Methodology: Measurements use a flat user-profile schema with string, integer, and boolean fields. Serialization performed with kotlinx.serialization (JSON) and protoc-generated stubs (Protobuf 3) on JVM 17. No compression applied; results reflect raw wire bytes before TLS framing.

This is not a rounding error. At 10k concurrent mobile clients polling every 30 seconds, a 65% payload reduction translates directly into egress cost and battery life. On constrained mobile networks, it is also the difference between a 200ms and a 600ms perceived response time.

---

Step 3: HTTP/2 Multiplexing — Where gRPC Pulls Away

REST over HTTP/1.1 has a structural problem: head-of-line blocking. A single slow response stalls every subsequent request queued behind it.

gRPC runs over HTTP/2 by default, which gives you multiplexed streams, HPACK header compression, and server push. Production teams migrating from REST/HTTP1.1 to gRPC/HTTP2 under sustained 5k+ concurrent connections have reported p99 latency reductions of 30–45% without changing application logic — see Uber Engineering's gRPC migration writeup and Cloudflare's HTTP/2 performance analysis for representative workloads. Results vary by payload shape, connection churn rate, and network topology. Benchmark your own system before treating these figures as guarantees.

GraphQL also runs over HTTP/1.1 in most default configurations. HTTP/2 is supported but requires explicit server and client configuration — and many teams skip this step, leaving the multiplexing advantage unrealized.

---

Step 4: GraphQL Query Execution Overhead

The pitch makes sense. Why send 40 fields when the client only needs 6?

# Client requests exactly what it needs
query UserCard {
  user(id: "abc") {
    name
    avatarUrl
    followerCount
  }
}

In practice, the resolver chain, field-level authorization checks, and DataLoader batching introduce per-query CPU overhead on the server. Under high concurrency, this is measurable. A well-structured REST endpoint returning a fixed shape will consistently outperform an equivalent GraphQL query at the 95th percentile of server-side latency.

A useful rule of thumb: GraphQL becomes a net positive when you have roughly 5 or more distinct client types consuming the same data with genuinely different field requirements. Below that, versioned REST endpoints or a BFF pattern tend to be simpler and faster. Treat this as a starting heuristic, not a number to defend in a design review.

---

Decision Matrix

Criterion	REST	gRPC	GraphQL
Payload efficiency	Low	High	Medium
Latency at scale	Medium	High	Medium
Mobile battery impact	Higher cost	Lower cost	Medium cost
Client flexibility	Low	Low	High
Ecosystem / tooling	Excellent	Good	Good
Browser native support	Yes	gRPC-Web¹	Yes
Streaming support	Limited	Native	Subscriptions

¹ gRPC-Web enables gRPC from browser clients via an HTTP/1.1-compatible framing layer (supported by Envoy, grpc-gateway, and official TypeScript and Dart client libraries). It does not support full bidirectional streaming, but unary and server-streaming calls work well.

---

Gotchas

Here are the gotchas that will save you hours.

Localhost benchmarks are lying to you. Your p99 numbers on a loopback interface mean nothing for mobile clients on LTE with 150ms base latency. Always benchmark under realistic network conditions and concurrency profiles.

HTTP/2 for GraphQL is opt-in, not default. Many teams assume their GraphQL setup inherits HTTP/2 benefits automatically. Verify both server and client are configured explicitly — the docs do not make this obvious.

Compression narrows the gap, but does not close it. The Protobuf numbers above are raw wire bytes with no compression applied. With gzip, the JSON gap narrows — but Protobuf still wins, and the HTTP/2 multiplexing advantage is independent of payload encoding.

The "5 client types" number is a conversation starter. Profile your actual query patterns before committing to GraphQL. If your client diversity does not clearly justify per-query field selection, a BFF pattern over REST will outperform GraphQL at lower operational complexity.

---

Conclusion

At scale, protocol choice stops being a preference and becomes an architecture constraint. Here is the minimal decision set to get this right:

• gRPC for internal service-to-service and high-throughput mobile APIs where you control both endpoints. The Protobuf + HTTP/2 combination pays dividends that JSON/HTTP1.1 cannot recover through application-level optimization. If browser clients are in scope, evaluate gRPC-Web before ruling it out.
• GraphQL for public-facing APIs or platforms with diverse client consumption patterns. Accept the query execution overhead as the cost of flexibility.
• REST where browser compatibility, third-party integration, or team familiarity outweighs raw performance. It remains the pragmatic default for most greenfield APIs.

Define your schema and serialization stack first. Then measure at the wire.