tRPC vs GraphQL in 2026
tRPC vs GraphQL in 2026
tRPC vs GraphQL in 2026 comes down to one trade: are you building a TypeScript-only monorepo with a single frontend, or an API that serves web, mobile, partners, and other languages? GraphQL still wins for cross-language clients, public schemas, and federated graphs. tRPC wins when every caller is your own TypeScript code. For new TS-only Next.js apps, neither may be the right answer at all.
This post is for engineering leads and founders who are about to commit to an API layer for the next two to four years. We will be honest about where each tool wins, what 2026 actually changed (tRPC v11, Apollo Federation v2, React Server Components going mainstream), and the decision most comparison posts skip: when REST plus Server Actions makes both choices irrelevant.
tRPC vs GraphQL: the short answer
Pick GraphQL if any of these are true: you serve native iOS or Android apps, you publish a public API, you have a polyglot backend, or you need a federated graph across multiple services and teams. Pick tRPC if every consumer of your API is TypeScript code in the same monorepo and you want the tightest type-safety loop available without a codegen step. If you are starting a new Next.js app and your only client is the same Next.js app, look hard at Server Actions and REST first.
Where GraphQL still wins in 2026
GraphQL is fifteen years old at this point and the ecosystem reflects it. The wins are real, and most "tRPC is better" posts gloss over them.
Cross-language ecosystem. A GraphQL schema is just text. Apollo Client targets Swift, Kotlin, Java, Go, Python, Rust, and a dozen others. If your iOS app needs to fetch a user with their last five orders, it speaks the same query language as your React frontend. tRPC has no equivalent. The whole point of tRPC is TypeScript inference, and that inference does not cross language boundaries.
Public and partner APIs. When external developers consume your API, they want a stable, documented, discoverable schema. GraphQL ships with introspection by default. Tools like GraphiQL, Apollo Studio, and Hasura turn a schema into a self-service portal. Stripe, Shopify, GitHub, and Contentful all expose GraphQL endpoints to third-party developers. Nobody ships tRPC as a public API.
Schema-first design with codegen. For larger teams, the schema is a contract that frontend and backend agree on before anyone writes a line of implementation. That separation scales. Mobile teams in Stockholm can codegen Swift types from a schema written by backend engineers in Lisbon, and neither team needs to read the other's code. tRPC's "types come from the server" model collapses that separation, which is fine for two engineers and painful for fifty.
Apollo Federation v2. Federation v2 is mature in 2026. Companies like Netflix, Expedia, and Wayfair run federated graphs that stitch dozens of subgraphs into one supergraph. Each subgraph is owned by a different team, deployed independently, and contributes a slice of the unified API. tRPC has no federation story because it does not have a schema to federate.
Tooling depth. Apollo Client, Relay (now RSC-aware via the Relay Compiler), GraphQL Yoga, Pothos, Hasura, WunderGraph, and Grafbase form an ecosystem you cannot recreate in a year of focused work. Caching, optimistic updates, persisted queries, and subscriptions are solved problems.
If your shape is multi-client, multi-team, or public, GraphQL is the boring correct answer. Boring is good for systems you cannot rewrite later.
Where tRPC wins in 2026
tRPC's pitch is small but sharp: if you control both ends of the wire and both ends are TypeScript, you should not have to write a schema twice.
Zero schema duplication. With GraphQL you write your types in TypeScript, write the schema in SDL, write resolvers that bridge them, run codegen, and consume the generated client. With tRPC you write a router with procedures, and the client gets the inferred types for free. No SDL, no codegen, no drift.
Refactoring confidence. Rename a server procedure and every client call site lights up red in your editor instantly. There is no "regenerate the client" step that someone forgets. For teams that ship daily, that loop is genuinely faster.
Smaller surface area. A complete tRPC setup is about fifty lines of code, one router file, and an HTTP handler. There is no separate server process, no schema registry, no Apollo Studio account. The infra footprint is closer to REST than GraphQL.
RSC-native in tRPC v11. tRPC v11 ships first-class support for React Server Components. You can call procedures directly from server components without an HTTP roundtrip when the call originates server-side, and the same procedure works as a client-side fetch when called from a client component. That dual-mode call site is a real DX improvement for Next.js App Router code.
Solo and small-team velocity. For a 2-5 engineer team building a Next.js SaaS with one web client, tRPC will feel like cheating compared to a GraphQL setup. The honest read of the trade-off is: tRPC trades long-term flexibility for short-term velocity. That trade is the right one more often than GraphQL maximalists admit.
Performance: it almost never matters
Every comparison post talks about performance. Almost none of them publish numbers. Pockit's 2026 benchmark fetches a user profile plus five orders over each protocol on a localhost setup:
| Protocol | Payload | p50 | p99 |
|---|---|---|---|
| REST (JSON) | 1,247 bytes | 12ms | 45ms |
| GraphQL | 834 bytes | 15ms | 55ms |
| tRPC (JSON) | 1,180 bytes | 11ms | 40ms |
| gRPC (proto) | 312 bytes | 4ms | 12ms |
Two things stand out. First, tRPC and REST are within a millisecond of each other. Second, GraphQL is the slowest of the three browser-friendly options, mostly due to query parsing and resolver overhead per request. Third, gRPC is in a different league, but you cannot speak gRPC from a browser without a proxy.
For 99% of SaaS apps, the bottleneck is the database query, not the wire protocol. A poorly indexed Postgres join will cost 200ms; the protocol contributes single-digit milliseconds. If anyone tells you to pick tRPC over GraphQL for performance reasons, they are solving a problem you do not have.
Head-to-head comparison table
| Factor | tRPC | GraphQL |
|---|---|---|
| Setup | ~50 LOC, one router file | Schema, resolvers, server, client tooling |
| Type safety | Inferred from TS code, zero codegen | Schema-first, codegen required |
| Cross-language clients | TypeScript only | Any language with a client |
| Public API readiness | Internal only | Designed for external consumers |
| Federation | No native concept | Apollo Federation v2 mature |
| RSC / Server Actions fit | Native in v11 | Works, but heavier |
| Tooling depth | Compact, growing | 15-year ecosystem |
| Best fit | TS monorepo, one frontend | Multi-client, multi-team, public |
The honest read: GraphQL is more capable and more complex. tRPC is less capable and less complex. The right answer is whichever matches the shape of your team and your client surface.
The third option most TS teams forget: Server Actions plus REST
Here is the part that comparison posts skip. If you are starting a new Next.js project in 2026, the question may not be tRPC or GraphQL at all.
Next.js Server Actions handle mutations as plain async functions you call from forms or client components. The framework wires up the HTTP layer for you, types flow through naturally, and there is no separate API to maintain. Server Components handle reads by calling your database or services directly on the server, returning HTML. For a lot of TS-only Next.js apps, that combination covers 80% of what you would have used tRPC or GraphQL for.
You then add a small REST surface for two specific use cases: webhooks (Stripe, Slack, GitHub) and any external consumer that is not your own Next.js app. REST plays well with CDN caching, OpenAPI tooling, and curl, all of which matter when third parties touch the endpoint.
The shape of a 2026 Next.js stack is more often:
- Server Components and Server Actions for the app's own UI.
- A few REST routes (
app/api/*/route.ts) for webhooks and public endpoints. - tRPC or GraphQL only when one of those does not fit.
If you are about to install tRPC out of habit, ask whether Server Actions could carry the load first. The answer is yes more often than people admit.
When to choose tRPC
- You ship a Next.js or Remix app and the only client is the same TS codebase.
- Your team is 2-10 engineers, all TypeScript, all in one monorepo.
- You want zero codegen and tight refactor loops.
- You will not need a non-TS client (mobile, third-party) in the next 18 months.
- You are already using React Server Components and want a procedure call style for non-RSC paths.
When to choose GraphQL
- You serve native iOS, Android, or React Native alongside web.
- You publish a public API or partner-facing endpoints.
- Your backend is polyglot (Go services, Python ML, Rust workers).
- You need a federated graph across multiple teams or services.
- You expect the schema to outlive any single backend implementation.
For teams making other stack choices in this same shape, our comparison of Clerk vs Auth0 vs NextAuth in 2026 walks through the same "TS monorepo vs multi-client" axis applied to authentication, and Zustand vs Jotai vs Redux Toolkit does the same for state.
The staffing question nobody asks
Most comparison posts stop at the technical decision. The harder question is who writes and maintains the API layer for the next 18 months.
tRPC needs strong TypeScript generalists who can think in terms of inferred types and procedure design. GraphQL needs schema-design discipline plus willingness to maintain the codegen pipeline, the resolver layer, and (at scale) the federation gateway. Those are different hires.
If your team is small and you go with tRPC, a mid-tier Cadence engineer at $1,000 per week can stand up a tRPC + Next.js + Prisma stack and ship features against it. If you go with GraphQL and want federation done right, you need a senior at $1,500 per week or a lead at $2,000 per week, the same range as for Toptal vs Andela talent, with a bias toward someone who has shipped Apollo at scale before. Every engineer on Cadence is AI-native by default, vetted on Cursor, Claude Code, and Copilot fluency in a voice interview before they unlock bookings, so schema design with AI assistance is part of the baseline rather than a premium tier.
Cadence's pool of 12,800 engineers covers both shapes. The point is not "book us." The point is: pick the API layer first, then staff the team to match. Picking GraphQL because Netflix uses it, then staffing two juniors to maintain it, is the most common failure mode we see.
If you are not sure which shape you are, the honest move is to see how Cadence compares to traditional hiring paths for week-by-week engineering, run a 48-hour trial on a senior with API-design experience, and let them sketch both options against your actual product before you commit.
What to do this week
- Map your client surface. List every consumer of your API: web, mobile, public, webhooks, internal services. If the list is "Next.js," you are in tRPC or Server Actions territory. If it has more than two entries, GraphQL deserves serious consideration.
- Try Server Actions first if you are on Next.js App Router. Build one mutation flow end-to-end. If the DX is good enough, you may not need an API layer at all.
- If you choose tRPC, start with v11 and the official Next.js adapter. Skip the React Query integration unless you actually need cache management beyond what RSC gives you.
- If you choose GraphQL, pick Pothos for schema-first ergonomics and Apollo Client or Relay on the consumer side. Plan for codegen from day one.
- Staff to match. Do not pick GraphQL with federation if your team is two engineers. Do not pick tRPC if you know an iOS client is six months out.
If you are stuck between tRPC and GraphQL with a small team and a tight timeline, the fastest unlock is usually a senior engineer who has shipped both. Cadence shortlists vetted engineers in 2 minutes with a 48-hour free trial, weekly billing, no notice period. See the alternative to traditional hiring and let someone with the scars sketch the right shape against your codebase.
FAQ
Is tRPC faster than GraphQL?
Marginally. Published 2026 benchmarks show tRPC at 11ms p50 versus GraphQL at 15ms p50 on identical operations. The difference is negligible compared to database query time, which usually dominates by an order of magnitude.
Can tRPC replace GraphQL for a public API?
No. tRPC requires a TypeScript client, so it cannot serve mobile apps in Swift or Kotlin, third-party developers in other languages, or partners who expect a discoverable schema. For public APIs, GraphQL or REST with OpenAPI remain the right choices.
Should new Next.js projects use tRPC or Server Actions?
For new TS-only Next.js apps in 2026, Server Actions handle most mutations and Server Components handle most reads. tRPC adds value mainly when you need procedure-style calls from code paths that are not RSC, or when you want a single API surface for a future React Native app sharing the TypeScript types.
Does GraphQL still need codegen in 2026?
Yes. Schema-first design implies a generated client to keep types in sync across the wire. Tools like graphql-codegen, Relay Compiler, and Apollo's tooling are still the norm and have improved meaningfully (faster builds, better RSC integration), but the codegen step has not gone away.
Can I migrate from tRPC to GraphQL later?
Yes, and many teams do once a second non-TypeScript client appears. The mapping from tRPC procedures to GraphQL resolvers is mechanical: each query procedure becomes a Query field, each mutation becomes a Mutation field, and Zod input schemas translate cleanly into GraphQL input types. Plan for one to two weeks of work for a mid-sized API.