GraphQL vs REST: Real-World Performance Test and Benchmarks

I ran these benchmarks because I was tired of articles claiming GraphQL is faster than REST (or vice versa) without showing their methodology. Both claims can be true depending on what you measure. Let me show you the actual numbers and what they mean.

The Test Setup

I built identical backends in both REST and GraphQL using Node.js + Fastify, connected to a PostgreSQL database with realistic data (100,000 users, 500,000 posts, 2,000,000 comments). All tests ran with k6 at 50 concurrent users for 60 seconds. The database had appropriate indexes. No artificial slow queries. Node.js docs were followed for optimal async patterns.

The test scenarios were chosen to represent the two situations where GraphQL is supposed to shine:

1. Simple read (single resource, single API call — REST's home turf)
2. Complex nested read (post + author + first 10 comments — GraphQL's supposed advantage)

Let me show you the same data queries in both styles first, then the numbers.

Test Scenario 1: Simple User Profile Fetch

REST endpoint:

// GET /api/users/42
// Returns: { id, name, email, avatarUrl, bio, createdAt }

app.get('/api/users/:id', async (req, res) => {
  const { rows } = await db.query(
    `SELECT id, name, email, avatar_url, bio, created_at 
     FROM users WHERE id = $1`,
    [req.params.id]
  );
  if (!rows.length) return res.status(404).send();
  res.json(rows[0]);
});

GraphQL query:

query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
    avatarUrl
    bio
    createdAt
  }
}

In this scenario, the client needs all six fields and GraphQL provides no reduction benefit. The queries hit the same database row.

Test Scenario 2: Post Feed with Author and Comments

This is the over-fetching scenario. A mobile app displays a post card showing: post title, first 100 characters of content, author name, author avatar, and comment count.

REST approach (3 requests):

// Request 1: GET /api/posts/123
// Returns full post object (all 20 fields including full content, metadata, etc.)

// Request 2: GET /api/users/456 (post.authorId)
// Returns full user object (all 15 fields)

// Request 3: GET /api/posts/123/comments/count
// Returns: { count: 847 }

REST approach with compound endpoint (1 request):

// GET /api/posts/123?include=author&fields=title,excerpt,author.name,author.avatarUrl,commentCount

app.get('/api/posts/:id', async (req, res) => {
  const { include, fields } = req.query;

  const post = await db.query(`
    SELECT 
      p.id,
      p.title,
      LEFT(p.content, 100) AS excerpt,
      u.name AS author_name,
      u.avatar_url AS author_avatar,
      COUNT(c.id) AS comment_count
    FROM posts p
    JOIN users u ON u.id = p.author_id
    LEFT JOIN comments c ON c.post_id = p.id
    WHERE p.id = $1
    GROUP BY p.id, u.name, u.avatar_url
  `, [req.params.id]);

  res.json(post.rows[0]);
});

GraphQL approach (1 request, exact fields):

query GetPostCard($id: ID!) {
  post(id: $id) {
    title
    excerpt  # Resolver returns first 100 chars
    author {
      name
      avatarUrl
    }
    commentCount
  }
}

The Benchmark Results

Scenario 1: Simple User Read

GraphQL loses on simple reads. The overhead comes from query parsing, validation, and resolver dispatching. This is not surprising — GraphQL was never designed to optimize simple single-resource reads. The 2ms difference is imperceptible to users, but throughput matters at scale.

Scenario 2: Post Feed — Naive REST (3 requests) vs GraphQL (1 request)

Here's where GraphQL genuinely earns its reputation. The naive REST approach — three separate requests for related data — is significantly slower, especially on mobile networks where each round trip adds 50–200ms of latency.

Scenario 2: Post Feed — Optimized REST (1 compound endpoint) vs GraphQL

This is the result that most GraphQL-vs-REST comparisons don't show: a well-designed REST endpoint with a compound query matches GraphQL's data efficiency and outperforms it on raw throughput.

The honest interpretation: GraphQL's performance advantage disappears when REST endpoints are designed well. GraphQL's real advantage is that it removes the need to design and maintain those compound endpoints — the client just asks for what it needs.

What Over-Fetching Actually Costs in Practice

Let me make the over-fetching problem concrete with a real example.

A user list endpoint in a mobile app displays 20 users per page: name, avatar, and last active date.

Over-fetching REST response (what a naive /api/users endpoint returns):

{
  "id": 1,
  "name": "Sarah Chen",
  "email": "sarah@example.com",
  "passwordHash": null,
  "bio": "Software engineer with 10 years...",
  "avatarUrl": "https://...",
  "lastActiveAt": "2026-05-30T14:22:00Z",
  "createdAt": "2023-01-15T08:00:00Z",
  "updatedAt": "2026-05-30T14:22:00Z",
  "preferences": { "theme": "dark", "notifications": {...}, "privacy": {...} },
  "stats": { "postsCount": 142, "followersCount": 893, ... }
}

That's perhaps 800 bytes per user × 20 users = 16KB per page, of which the app uses maybe 150 bytes.

GraphQL response for the same view:

{
  "name": "Sarah Chen",
  "avatarUrl": "https://...",
  "lastActiveAt": "2026-05-30T14:22:00Z"
}

150 bytes × 20 users = 3KB. The 80% payload reduction is real and matters for mobile users on limited data plans.

But note: the optimized REST approach would just return those same three fields. The question is whether you want that optimization to be client-driven (GraphQL) or server-defined (REST).

HTTP Caching: REST's Hidden Advantage

One benchmark number I haven't shown yet: cache hit rates.

In production, REST responses behind a CDN can achieve 60–90% cache hit rates on read-heavy endpoints. Every cached response takes 0ms of server processing and typically ~5ms of CDN edge latency.

GraphQL, sent as POST requests, is not cacheable by HTTP CDNs without custom work. Apollo's persisted queries and GET-based query caching help, but it's genuinely more complex than REST's default behavior.

For a social feed endpoint accessed 1 million times per day:

*Client-side cache depends heavily on implementation and query variation.

For content that changes infrequently (product listings, blog posts, public profiles), REST's HTTP caching advantage is massive. For real-time or frequently changing data, caching matters less and GraphQL's data fetching flexibility becomes more valuable.

When to Choose GraphQL

Based on these benchmarks and my experience in production:

GraphQL clearly wins when:

• Your frontend clients have diverse, complex data requirements (dashboard apps, mobile apps with many different screens)
• You're building a public API where third-party clients need flexibility
• Your team is tired of negotiating what each REST endpoint should return
• You have significant over-fetching causing real user-visible problems (especially mobile)
• You're building a product where the data requirements change frequently

REST clearly wins when:

• Simple CRUD operations dominate
• You need HTTP caching (CDN, browser cache) to work automatically
• Your team is small and fast iteration speed matters more than API flexibility
• You're building a public API that non-developers will consume (REST is more familiar)
• Your endpoints are few and well-defined — the GraphQL overhead isn't worth it

The verdict: For a data-heavy, client-diverse, mobile-first application, GraphQL's benefits are real and worth the implementation complexity. For a straightforward API with well-defined clients, REST with thoughtful endpoint design performs better and is simpler to operate.

Our REST API vs GraphQL vs gRPC comparison covers the architectural trade-offs in more depth, and our API tutorial for beginners is a good foundation if you're newer to API design. If you're thinking about the authentication layer for either approach, our JWT authentication guide covers patterns that work with both.

The Honest Verdict

GraphQL is not inherently faster than REST. REST is not inherently better than GraphQL. The performance difference is use-case dependent, and the over-fetching problem that GraphQL solves can also be addressed with well-designed REST endpoints.

GraphQL's real value proposition in 2026 is developer experience and flexibility — particularly for frontend teams who are tired of waiting for backend developers to add new fields to existing endpoints, or building a BFF layer that serves multiple clients with very different data needs.

If that describes your situation, GraphQL is worth the complexity. If it doesn't, REST is probably the right default. Both choices are defensible in 2026 — just make yours based on your actual requirements, not benchmarks that favor one scenario over another.

Frequently Asked Questions