Comparison

See how oRPC compares to tRPC and Hono across type safety, OpenAPI support, framework integrations, and runtime performance.

oRPC, tRPC, and Hono all deliver end-to-end typesafe APIs in TypeScript, but they take different approaches. tRPC focuses on RPC for full-stack TypeScript apps, Hono is a general-purpose web framework with an RPC feature, and oRPC combines typesafe RPC with first-class OpenAPI support.

Features

• ✅ First-class, built-in support
• 🟡 Lacks features or requires third-party integrations
• 🛑 Not supported or not documented

Type Safety

oRPC types errors per procedure or globally: throw a plain ORPCError, declare errors on a single procedure or a shared builder, or define them once and reuse them everywhere via an error factory. tRPC exposes one global error shape, and Hono only types errors returned with an explicit status code. oRPC is also the only one that types binary data in both directions: tRPC and Hono cover uploads but not typed binary responses.

API Design & OpenAPI

oRPC serves the same procedures over its RPC protocol and RESTful OpenAPI endpoints and generates the OpenAPI spec natively, while tRPC and Hono depend on extra packages for OpenAPI. Native types like Date or Map work out of the box in oRPC; tRPC needs a transformer, and Hono has no serialization layer: what you pass to c.json() is what you get.

Integrations & Ecosystem

Every oRPC integration above is first-party, while tRPC leaves several to community packages and Hono’s typed client is a bare fetch wrapper you wire into query libraries yourself.

Performance

All numbers were measured on 2026-08-09 with oRPC 2.0.0-beta.26, tRPC 11.18.0, and Hono 4.13.1, and are reproducible from middleapi/orpc-benchmarks. Handlers are no-ops with pass-through validation, so the results measure framework overhead only.

Throughput

oRPC handles about 4.3x as many requests as tRPC over HTTP and 4.8x over WebSocket. oRPC and Hono are effectively tied on RESTful throughput.

Clinic Doctor Profiles

Every run also profiles the server with Clinic.js Doctor:

The profiles show where the throughput gap comes from. Over HTTP, oRPC serves over 4x tRPC’s requests at similar CPU usage (~104% vs ~113%), so its per-request CPU cost is several times lower, and its event loop stays responsive: 0.04 ms average delay versus tRPC’s 0.70 ms. Memory stays flat between 71 and 110 MB in every oRPC run, while tRPC’s HTTP run climbs to 247 MB, more than double oRPC’s highest reading, a sign of per-request allocation pressure. oRPC and Hono profile nearly identically, matching their tied throughput.

tRPC’s low WebSocket CPU is not an advantage: the cpu: performance issue means the server cannot keep the CPU busy, so throughput is capped elsewhere in the stack.

Type-Checking Performance

On a large, fully typed project with 3,000 procedures across 1,501 routers, oRPC type-checks about 20% faster than tRPC and uses about 28% less memory:

Hono is excluded: its RPC types hit documented limits at this scale and need workarounds like pre-compiled client types, an issue oRPC avoids by design.

Bundle Size

Bundle sizes for a minimal client and server pair, measured the same day. tRPC includes superjson to match oRPC’s built-in native types, and Hono includes @hono/node-server to match the Node.js servers in the other bundles.

Measure yourself: oRPC · tRPC · Hono