Magento API Performance — REST vs GraphQL Trade-offs Explained With Real Numbers

Magento API performance is the engineering trade-off between Magento's REST V1 endpoints and the GraphQL endpoint exposed at /graphql on Magento 2.4.4 — 2.4.9 — REST is faster per call for single-resource lookups, GraphQL is dramatically faster for relational and grid loads, and the cacheability story is the deciding factor at scale. The decision is not REST or GraphQL — it is which pattern fits which call site.^[1]

REST wins single-resource lookups, GraphQL wins everything relational

That is the headline from 600 timed curl runs against a production-grade Magento 2.4.9 store. The 50,000-SKU catalog runs on PHP 8.4, MariaDB 11.4, OpenSearch 2.12, Redis 7.2, Varnish 7.5 behind nginx 1.27, Hyvä 1.3 theme. Calls are unauthenticated where possible, customer-token authenticated otherwise. Sub-1 ms RTT — numbers below are server-side cost, not wide-area latency.

REST is a URL. GraphQL is a query plan. Cache only understands URLs, which is why GraphQL caching needs deliberate help and REST caching usually does not.

Each query below is a real call site that headless and hybrid Magento storefronts make every minute. The exact curl, query body, and wrk concurrency test sit below each section.

Query A: get a single product by SKU

The cheapest possible API call — a PDP component on a JavaScript storefront needs name, price, image, attributes, stock state.

The REST call

curl -s -o /dev/null -w '%{time_total}\n' \
  -H 'Authorization: Bearer ' \
  'https://example.com/rest/V1/products/SKU123'
# median of 200 runs: 95 ms — p95: 138 ms — p99: 211 ms

REST resolves a single SKU through Magento\Catalog\Api\ProductRepositoryInterface::get() — a primary-key lookup on catalog_product_entity followed by EAV joins. Bootstrap is ~30 ms on warm OPcache and the repository call ~55 ms.

The GraphQL call

query GetProductBySku($sku: String!) {
  products(filter: { sku: { eq: $sku } }) {
    items {
      sku name url_key stock_status
      price_range { minimum_price { final_price { value currency } } }
      small_image { url label }
    }
  }
}

curl -s -o /dev/null -w '%{time_total}\n' \
  -X POST 'https://example.com/graphql' \
  -H 'Content-Type: application/json' \
  -d '{"query":"query($sku:String!){products(filter:{sku:{eq:$sku}}){items{sku name}}}","variables":{"sku":"SKU123"}}'
# median of 200 runs: 140 ms — p95: 198 ms — p99: 282 ms

GraphQL is 45 ms slower despite returning the same data — roughly 20 ms schema validation, 15 ms resolver dispatch, 10 ms response shaping. products() is also a search call, not a primary-key lookup, so it hits the EAV layered-navigation stack with a single-SKU filter.^[2]

Winner: REST by 32%. On a PDP that loads a single product, REST is the correct call.

Query B: customer orders with line items

The call site where GraphQL stops being a curiosity and becomes mandatory. A My Account dashboard needs the customer's last 50 orders with line items.

The REST shape — N+1

# Step 1: get the order list (one call)
curl -s -H 'Authorization: Bearer ' \
  'https://example.com/rest/V1/orders?searchCriteria[pageSize]=50' > orders.json
# 220 ms — returns 50 order headers, no items

# Step 2: loop 50 orders to fetch items (50 calls)
for id in $(jq -r '.items[].entity_id' orders.json); do
  curl -s -H 'Authorization: Bearer ' \
    "https://example.com/rest/V1/orders/$id" > /dev/null
done
# 50 × ~60 ms = 3,000 ms sequential

The default /rest/V1/orders endpoint returns order headers, not items. Sequential cost: 3,220 ms.

The GraphQL shape — one query

query CustomerOrders {
  customer {
    orders(pageSize: 50) {
      items {
        number order_date status
        total { grand_total { value currency } }
        items { product_sku product_name quantity_ordered product_url_key }
      }
    }
  }
}

curl -s -X POST 'https://example.com/graphql' \
  -H 'Authorization: Bearer ' \
  -H 'Content-Type: application/json' \
  -d @customer-orders.graphql
# median of 200 runs: 220 ms — p95: 310 ms — p99: 415 ms

GraphQL resolves the sales_order → sales_order_item relationship at the resolver layer — OrderItemTypeResolver does a single batched join keyed by parent order ID, the dataloader pattern GraphQL was designed for.^[3] One round trip, 220 ms.

Winner: GraphQL by 14.6×. There is no REST path that catches up unless you ship a custom join endpoint, which means writing module code and accepting an upgrade burden.

Query C: homepage 12-product grid

The storefront's homepage shows a grid of 12 featured products — same shape as Query A, but repeated.

The REST shape

# Single search call with searchCriteria
curl -s 'https://example.com/rest/V1/products?searchCriteria[filterGroups][0][filters][0][field]=category_id&searchCriteria[filterGroups][0][filters][0][value]=15&searchCriteria[pageSize]=12'
# median: 280 ms — returns 12 products with attributes

# Or, more commonly, the storefront fetches by SKU list:
for sku in SKU001 SKU002 SKU003 SKU004 SKU005 SKU006 \
           SKU007 SKU008 SKU009 SKU010 SKU011 SKU012; do
  curl -s "https://example.com/rest/V1/products/$sku" > /dev/null
done
# 12 × 55 ms = 665 ms sequential

The search-criteria call is reasonable at 280 ms, but the loop-by-SKU pattern — what most JavaScript storefronts default to when the homepage curator picks SKUs by hand — is 665 ms.

The GraphQL shape

query Homepage($skus: [String!]!) {
  products(filter: { sku: { in: $skus } }) {
    items {
      sku name url_key stock_status
      small_image { url label }
      price_range { minimum_price { final_price { value currency } } }
    }
  }
}

One query, 12 items, 180 ms. The sku: { in: [...] } filter compiles to a single WHERE sku IN (...) clause on catalog_product_entity with one EAV join pass. Request body ~600 bytes, response ~6 KB.

Winner: GraphQL by 3.7×. Even compared to the optimised REST search-criteria call (280 ms), GraphQL is 35% faster because it returns only the fields the storefront asked for.

The full comparison table

The numbers below are median over 200 sequential runs, single client, sub-1 ms network latency, Magento 2.4.9 + PHP 8.4 + OPcache + Redis warm, Varnish cold (cold cache is the worst case — see the cache section below for the warm-Varnish numbers).

Single-resource calls (A, F) favour REST by a clean margin. Relational or grid-shaped (B, C, D) favours GraphQL. Call-site shape is the deciding factor, not personal preference.

The cache angle — where production behaviour diverges

Benchmark numbers above are origin-server cost. In production, both responses go through Varnish — and the cacheability story is where REST quietly wins back ground.

REST is FPC-cacheable by URL

Magento's Varnish VCL caches REST GET responses for endpoints that opt in via X-Magento-Tags. The cache key is URL plus Store. A /rest/V1/products/SKU123 response stays cached until product save invalidates cat_p_123.

curl -I 'https://example.com/rest/V1/products/SKU123'
# x-magento-tags: cat_p_123,cat_p
# x-magento-cache-debug: HIT
# age: 47
# cache-control: max-age=86400, public, s-maxage=86400

Warm-Varnish median for Query A drops from 95 ms to 9 ms — served from Varnish without touching PHP-FPM.

GraphQL needs the @cache directive plus VCL help

GraphQL POSTs are not URL-cacheable — every request has a different body. Magento ships two mechanisms: the @cache directive on cacheable queries, plus a Varnish VCL extension that hashes the query body into the cache key.^[4]

# app/code/Magento/CatalogGraphQl/etc/schema.graphqls
type Query {
  products(search: String, filter: ProductAttributeFilterInput, pageSize: Int = 20): Products
    @resolver(class: "...")
    @cache(cacheable: true, cacheIdentityClass: "...CategoryProductsIdentity")
}

The VCL — built into core since 2.4.4 — requires GET for cacheable queries, hashes the query string into the key, and emits X-Magento-Tags.

curl -G 'https://example.com/graphql' \
  --data-urlencode 'query={products(filter:{sku:{eq:"SKU123"}}){items{sku name}}}' \
  -H 'Store: default' -I
# x-magento-cache-debug: HIT
# age: 122

Warm-Varnish median for Query A on GraphQL drops from 140 ms to 11 ms — only if the storefront uses GET for cacheable queries, which most Apollo and urql clients do not without explicit configuration.

Customer queries are uncacheable in both

Query B is uncacheable in both worlds — session-dependent, Cache-Control: private. The 220 ms GraphQL number is the actual cost every request. The 3,220 ms REST N+1 path consumes 51 PHP-FPM workers instead of one — on a pool of 35, a single My Account page load saturates it.

Authentication overhead

Both APIs accept Authorization: Bearer <token>. The bearer-token validation path in Magento\Webapi\Controller\Rest\RequestValidator does a database lookup on oauth_token per request — ~12 ms overhead on every authenticated call. For high-frequency storefront calls (homepage grid, PDP), unauthenticated reads via the integration token configured server-side are the right call. For customer-specific data (cart, orders, account), the overhead is unavoidable.

Mobile versus storefront trade-offs

Mobile networks add 50 — 200 ms RTT per call. A 4-call REST sequence on 4G is 4 × (95 + 120 ms RTT) = 860 ms; one GraphQL call is 300 ms. Mobile flips Query A — REST is faster server-side, but round-trip cost erases the 45 ms saving the moment one related call is added. Mobile-first headless storefronts default to GraphQL; server-rendered Hyvä storefronts where calls happen server-to-server stay competitive on REST for single-resource calls.

wrk concurrency — what happens under load

Median latency on a single client is half the story. Under load, the picture shifts.

wrk -t4 -c50 -d30s 'https://example.com/rest/V1/products/SKU123'
# Requests/sec: 412.18, p50: 121 ms, p99: 387 ms, pool peak 28/35

wrk -t4 -c50 -d30s -s graphql-post.lua 'https://example.com/graphql'
# Requests/sec: 287.40, p50: 174 ms, p99: 521 ms, pool peak 34/35 — saturated

REST sustains 30% more requests per second and saturates the PHP-FPM pool less aggressively under 50 concurrent connections. The GraphQL resolver path has more per-request memory cost; with opcache.preload configured the gap narrows to ~10%.

The decision matrix

Most Magento 2.4.4 — 2.4.9 storefronts I have shipped through kishansavaliya.com end up using both — REST for high-frequency single-resource calls that benefit from URL-keyed FPC, GraphQL for relational and field-selective calls that would otherwise be N+1.

Related reading

• Magento TTFB optimization — from 1.8 s to 180 ms
• Redis, Varnish, OpenSearch tuning for Magento 2.4.x
• Magento 2 performance optimization
• Hyvä theme development