REST, tRPC and GraphQL in 2026: who owns the contract decides

In May 2022 someone opened a discussion on the tRPC repository asking whether a monorepo was mandatory. The maintainer's answer in Discussion #1860 is still the sharpest thing written about this comparison: without a shared repo you lose "the technology's primary superpower," and an organisation that needs separate repositories, or a server implementation it can hide, should use GraphQL or OpenAPI instead. That is the author of a tool drawing a boundary around his own tool, and the boundary is organisational rather than technical.

It answers the 2026 version of the question better than any benchmark: the contract format you can afford is decided by who owns the contract. A follow-up in June 2023 repeats the advice for multi-team setups.

Adoption has not read the memo.

Nothing in that curve looks like a tool people are outgrowing; the growth rate itself accelerated, roughly doubling in one year and then more than tripling in the next. What it does suggest is a lot of teams adopting a contract format whose author has publicly bounded it to the case where one team owns both ends. Most of them will discover the boundary the week they hire.

What the contract physically is decides everything else

The three differ less in what they can express than in what artifact carries the agreement.

tRPC's contract is a TypeScript type. The server exports export type AppRouter = typeof appRouter, the client does import type { AppRouter } and hands it to createTRPCClient, and that import is erased at compile time. No generated file, no schema document, no codegen step — and no artifact that could be reviewed, published or versioned independently of the source. Runtime validation with Zod or any Standard Schema library is a separate, optional decision; without it you have compile-time safety and nothing enforcing the shape at the wire.

GraphQL's contract is a document. SDL is a language-independent IDL, every field is backed by a resolver the implementer supplies, and the schema can be read, diffed and reviewed by people who will never open the server repository. REST has no mandatory contract at all: URLs and status codes are convention. OpenAPI supplies an optional formal document, which generators like openapi-typescript and orval turn into typed clients — but nothing compiles that document against the running implementation.

This is also why the framing is not one blogger's opinion. Pedro Teixeira's comparison on metaduck.com (August 2025) scores tRPC 2/5 against GraphQL's 4/5 on "Team Independence," arguing the server dictates what the client can fetch and the frontend team therefore waits on the backend team for every data change. That is the same mechanism the maintainer described three years earlier, reached independently and described as a cost rather than as a design choice. Both readings are correct.

Adoption numbers answer a different question than yours

Download counts measure how many teams already made the call, not whether it was right.

The interesting bar is graphql-yoga's. A frequently recirculated secondary estimate put Yoga near 800K a week against Apollo's 2M; the direct registry pull is roughly double that, which makes "Yoga is the niche alternative" a statement with a shelf life. Apollo still leads, and the ratio direction holds.

Survey data points the other way and measures something else again. Postman's State of the API 2025, 5,700-plus respondents, multi-select so the figures do not sum: REST 93%, GraphQL 33%. Neither gRPC nor tRPC was broken out as a category, which tells you where the survey's centre of gravity sits. There is no independent counterpart for GraphQL specifically — Devographics' State of GraphQL ran once, in 2022, and has not returned.

One number deserves less trust than its prominence suggests. trpc.io names Google, Netflix, PayPal, Mistral and Pleo on its homepage and repeats "even big ones like Netflix & Pleo" in the FAQ. No engineering blog, changelog or conference talk from Google, Netflix, PayPal or Mistral surfaced anywhere in this research to confirm the claim. The users independent technographic scanning does turn up are 60-to-900-person companies, which is exactly the shape the mechanism predicts.

Versioning is where the ownership question gets expensive

None of the three has a satisfying answer, and the shape of each failure is different.

GraphQL has no native versioning story at all, so every serious provider built one. Shopify runs calendar versions — 2026-01, 2026-04, 2026-07, with 2026-10 already at release candidate — supported at least twelve months with at least nine months of overlap. GitHub instead distinguishes "breaking" from "dangerous" schema changes, announces at least three months ahead and ships only on quarterly boundaries, with deprecations scheduled well in advance. Both are process built on top of a spec that declines to provide one.

REST's convention is stronger, and Stripe is the reference implementation: dated versions like 2026-06-24.dahlia, monthly backward-compatible releases within a major, two breaking releases a year. A published convention only binds a provider that means it.

tRPC's version is whatever is deployed, which is a genuine advantage while one pipeline ships both ends and a liability the moment it does not. cal.com is the project's own production reference, and its co-founder named "undocumented breaking changes" as a known cost of their internal tRPC APIs in an April 2024 Hacker News comment. A client you cannot redeploy on demand — anything sitting in an app store — turns that property into an outage.

Each contract costs something different to keep alive

tRPC bills you in compiler seconds. Discussion #2448 (August 2022) reports 5-7 second autocomplete on a 40-endpoint router with "type instantiation is excessively deep"; #3024 reports 8-plus seconds from chained Zod .omit() calls; #5508 (February 2024, M1 Max, 32 GB) describes 4-8 second type resolution as "close to unusable," with no maintainer response. The project's own engineering on this was real and partial.

Two further tRPC costs belong in the ledger. GHSA-pj3v-9cm8-gvj8 (CVE-2025-43855) was an unauthenticated WebSocket denial of service affecting v11.0.0 through v11.1.0, patched in v11.1.1; multi-instance subscription fan-out still has no built-in answer, so teams build their own Redis bridge. And the OpenAPI escape hatch closed: trpc-openapi was archived with a last push of 19 November 2024, after its maintainer went roughly a year without commits and issues piled up against Next.js 14 and tRPC v11. The job moved to a competitor rather than into tRPC — oRPC 1.0 shipped in April 2025 with OpenAPI generation built in, marketing itself against tRPC with claims of 1.6x faster type-checking, 2.8x faster runtime and 2.6x lower peak memory. Those are the vendor's own figures. A targeted search for critical or comparative independent commentary on oRPC found none at all, so treat them as unchallenged rather than as confirmed.

GraphQL bills you in data-access discipline. GitLab's public tracker still carries open N+1 issues on its own production GraphQL API, including #517805, where a single query fires 664 database queries for a 100-item page through per-item epic lookups.

The top two bars are the point. Naive traversal costs about the same whichever protocol carries it, and batching buys back a factor of five to sixty in both worlds — the fix is architectural, not a property of the query language. What GraphQL changes is who triggers the pattern: with client-defined queries, a shape nobody load-tested can arrive in production without a deploy.

Caching is the second recurring bill. One POST endpoint defeats URL-keyed HTTP and CDN caching, so the response cache has to be rebuilt out of persisted queries, normalisation or a dedicated product. Apollo's answer is a paid release train — Federation v2.12 (November 2025, LTS) added a @cacheTag directive, and v2.15 (July 2026, LTS) rewrote composition in Rust. Apollo also moved GraphOS Team billing from query-based to user-based pricing around June 2025, citing customers who found usage pricing impossible to forecast.

Exposure is the third. Escape.tech scanned 160 public GraphQL endpoints in July 2024 and found roughly 69% with unrestricted resource-consumption issues. The widely repeated "80% of GraphQL APIs are vulnerable" line is a misreading of that same scan, and the narrower figure is the one to quote.

REST's running cost is the quietest and the easiest to defer. The OpenAPI document is accurate the day it ships and drifts as soon as a field changes without it; the standard mitigation is contract testing in CI with Dredd or Schemathesis, which is work that never announces itself as urgent. The spec itself keeps moving in small steps — OpenAPI 3.2.0 landed 19 September 2025 with structured tags and first-class streaming media types, explicitly framed as an incremental release rather than a 4.0.

The GraphQL retreat is discourse, not release notes

Critical writing about GraphQL had a strong year. John James's "the enterprise honeymoon is over" (December 2025) drew 255 points and 235 comments on Hacker News, the highest engagement of anything in this research, arguing that enterprises already solve overfetching with BFFs and GraphQL merely relocates it. Jens Neuse's "I was wrong about GraphQL" (December 2024) is more striking for its author than its argument: the CEO of a company selling GraphQL federation tooling now recommends tRPC for monoliths and reserves GraphQL for genuine cross-team federation.

The release logs say something else. GitHub shipped GraphQL schema features throughout 2025 and added resource-consumption limits that September; Shopify has quarterly API versions scheduled into October 2026; Netflix's dgs-framework reached v12 in April 2025; Meta's Mobile GraphQL team published its own status in March 2025.

The scale numbers point the same way. At GraphQLConf 2025, Airbnb presented Viaduct, its internal federated platform serving around 1,000 contributing developers, and Booking.com described a federated graph handling 11 billion requests a day.

No primary-source example of a large named company dropping GraphQL turned up in either research pass. What ended was its status as the default answer, not its deployment — and both of those facts are load-bearing for a team deciding today.

How I would choose

By who owns the contract, then by which consumers you cannot redeploy.

1. One full-stack developer or one team, one repo, one TypeScript deploy

   tRPCoRPC if you may need to expose OpenAPI later

   This is the designed case, stated as such by the maintainer. The absent codegen step and the instant rename-across-the-stack are real and hard to give up. oRPC covers the same ground with OpenAPI generation in the box, at the price of a library whose comparative claims nobody independent has checked.

2. Separate frontend and backend teams, separate repos or release trains

   GraphQL or REST + OpenAPI

   The tRPC contract cannot be jointly owned here without publishing a types package and re-inventing versioning around it. Both remaining options give you an artifact that can be reviewed before either side ships.

3. A public API with consumers you cannot deploy

   REST + OpenAPI, versioned the way Stripe versions

   Dated versions with monthly backward-compatible releases and two breaking cuts a year is the most battle-tested contract discipline available. GitHub's dispatch incident is what the alternative looks like.

4. Web, iOS and Android clients with divergent data needs and a platform team to fund

   GraphQL, with the caching and cost-limiting work budgeted up front

   Airbnb, Booking.com and Meta demonstrate this works at scale. They also demonstrate what it costs: query cost limiting, persisted queries and a dedicated schema owner are not optional extras here.

5. Any consumer or service not written in TypeScript

   GraphQL or REST, decided by the previous rows

   tRPC's contract is a TypeScript type. A Python or Go consumer cannot import it, and the workaround — generating a second contract from the first — hands you both formats' costs at once.

What would change the answer

The maintainer's boundary is the load-bearing claim here, and the honest way to hold it is to name what would move it. A first-class OpenAPI or schema-emission path shipped by tRPC itself would do it, because that turns the erased type into a publishable artifact. No such work is announced: v11 stabilised on 21 March 2025, v11.18.0 shipped 18 June 2026, commits continue, and no v12 roadmap exists anywhere in the blog, docs or release discussions.

The second thing to watch is oRPC. Its 1.6x/2.8x/2.6x advantages over tRPC are vendor-published and, as of September 2026, entirely unchallenged — not disputed, simply unexamined. One independent benchmark with a stated harness would either promote it to a default recommendation for the solo case or retire the claims.

The third is a gap rather than an event. Despite a decade of "GraphQL versus REST performance" content, no rigorous independent throughput comparison of the three with a disclosed harness exists; roughly ten candidates were reviewed for this piece and every one either hid its method or could not be reached. Anyone who publishes one changes the shape of this argument permanently.