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
| Feature | oRPC | tRPC | Hono |
|---|---|---|---|
| End-to-end typesafe input/output | ✅ | ✅ | ✅ |
| End-to-end typesafe errors | ✅ | 🟡 | ✅ |
| End-to-end typesafe File/Blob | ✅ | 🟡 | 🟡 |
| End-to-end typesafe Server-Sent Events | ✅ | ✅ | 🛑 |
End-to-end typesafe ReadableStream<Uint8Array> |
✅ | 🛑 | 🛑 |
| Typesafe at scale | ✅ | ✅ | 🛑 |
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
| Feature | oRPC | tRPC | Hono |
|---|---|---|---|
| Implementation-first approach | ✅ | ✅ | ✅ |
| Contract-first approach | ✅ | 🛑 | ✅ |
| OpenAPI spec generation | ✅ | 🟡 | ✅ |
| Standard Schema (Zod, Valibot, ArkType, …) | ✅ | ✅ | 🟡 |
| Native types (Date, URL, Set, Map, …) | ✅ | 🟡 | 🛑 |
| Custom serializers | ✅ | ✅ | 🛑 |
| Bracket notation | ✅ | 🛑 | 🛑 |
| Lazy router (code splitting, faster cold starts) | ✅ | ✅ | 🛑 |
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 come from middleapi/orpc-benchmarks and were measured on the same machine with oRPC 2.0.0-beta.35, tRPC 11.18.0, and Hono 4.13.1. Handlers are no-ops with pass-through validation, so the results measure framework overhead only.
Throughput
| Scenario | oRPC | tRPC | Hono |
|---|---|---|---|
| RPC over HTTP (req/s avg) | 18,845 | 4,299 | n/a |
| RPC over WebSocket (req/s avg) | 23,815 | 5,054 | n/a |
| OpenAPI (RESTful) over HTTP (req/s avg) | 18,014 | n/a | 16,932 |
oRPC handles about 4.4x as many requests as tRPC over HTTP and 4.7x over WebSocket. oRPC and Hono are close on RESTful throughput, with oRPC about 6% ahead.
Clinic Doctor Profiles
Every run also profiles the server with Clinic.js Doctor:
| Run | CPU (avg) | Memory (RSS) | Detected issues | Full report |
|---|---|---|---|---|
| RPC over HTTP · oRPC | ~104% | 73-91 MB | none | view |
| RPC over HTTP · tRPC | ~113% | 73-247 MB | none | view |
| RPC over WebSocket · oRPC | ~104% | 71-109 MB | none | view |
| RPC over WebSocket · tRPC | ~41% | 67-75 MB | cpu: performance | view |
| OpenAPI over HTTP · oRPC | ~104% | 73-92 MB | none | view |
| OpenAPI over HTTP · Hono | ~103% | 71-95 MB | none | view |
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 109 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, in line with their close 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 32% faster than tRPC, uses about 31% less memory, and needs about 19% fewer type instantiations:
| Metric | oRPC | tRPC |
|---|---|---|
| Total time | 1.67s | 2.47s |
| Memory used | 469 MB | 677 MB |
| Instantiations | 2,198,327 | 2,719,560 |
Hono has no column because it does not scale to this size. Its RPC types hit known limits well before this point and the project becomes effectively unusable, an issue oRPC avoids by design.
Bundle Size
Bundle sizes for a minimal client and server pair, measured with the same versions. 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.
| Metric | oRPC | tRPC | Hono |
|---|---|---|---|
| Minified | 46.4 kB | 83.3 kB | 43.3 kB |
| Minified + gzip | 14.5 kB | 25.6 kB | 16.4 kB |