Is GraphQL still worth using in 2026?

• Yes, but with a more specific answer than a year ago — it's worth using where it earns its keep, and there's now genuine consensus on where that is.

The most notable shift in the 2026 conversation

• A prominent voice in the space (Jens Neuse, who's spent six years building GraphQL infrastructure) published a widely-cited reassessment: GraphQL's real value isn't beating REST or gRPC on performance or payload efficiency — it's that it enables Federation and cross-team collaboration. His conclusion after years of hands-on building: monolithic GraphQL APIs generally don't justify their complexity anymore; his team now uses tRPC for monoliths and reaches for GraphQL specifically when they need Federation at enterprise scale. That's a meaningful signal — someone who was deeply invested in the ecosystem is now much more selective about it.

Where GraphQL genuinely earns its complexity in 2026

Multiple divergent client types (web, mobile, third-party) pulling different shapes from the same underlying data

A Backend-for-Frontend layer aggregating multiple services or REST/gRPC microservices into one client-facing query

Complex, deeply nested/relational data where access patterns vary a lot between consumers

Frontend teams that need to iterate independently without waiting on new backend endpoints

Where it doesn't

• Simple CRUD APIs with predictable data shapes — one engineer's account: an inventory API where every endpoint mapped cleanly to a resource; adding GraphQL "would have been pure overhead," and they got sub-50ms responses with plain Redis + CloudFront caching, no schema stitching or resolver complexity needed
• Public APIs — REST still powers roughly 83% of these, mainly because native HTTP/CDN caching, curl-debuggability, and universal tooling matter more than query flexibility when you don't control the client
• Single-team TypeScript monoliths — tRPC increasingly wins here: same type-safety benefit as GraphQL, without a schema language, codegen step, or the operational tax of query complexity analysis and persisted queries
• Teams without dedicated API infrastructure investment — the real, consistent complaint across sources: GraphQL's operational cost is genuinely higher than REST's. One team reported REST onboarding takes days, GraphQL takes weeks to months before developers are truly productive, and GraphQL required them to build custom logging, complexity analysis, and schema tooling that REST got "for free" from off-the-shelf solutions

The honest numbers, held loosely

• Adoption figures circulating in 2026 (GraphQL "in production at 61%+ of enterprises," "340% growth since 2023") mostly trace back to vendor-adjacent blog posts rather than a single rigorous survey — treat them as directional, not precise. What's consistent across independent sources, though: 93% of teams still use REST for at least part of their stack, and the dominant real-world pattern is GraphQL as an aggregation layer sitting in front of REST/gRPC services (Netflix, GitHub, Shopify, Airbnb, NYT all run this hybrid), not GraphQL replacing REST outright.

Bottom line

• GraphQL is absolutely still worth using in 2026 — but the mature 2026 take is narrower and more confident than the 2018-2021 hype cycle: use it specifically for the BFF/aggregation/federation layer in front of diverse clients or complex service graphs, not as a default choice for every new API. If you're a single-team TypeScript shop with one frontend, seriously evaluate tRPC first; if you're building a public API, REST is still the safer default; if you have multiple client types or multiple teams needing independent schema ownership, GraphQL (specifically via Federation) is where it clearly wins.