Benchmarking Backend Frameworks & ORMs: Go vs. Express (Raw SQL) vs. NestJS (Prisma)

When designing backend APIs, developers frequently debate the trade-offs between developer experience (DX) and runtime performance. Frameworks with strong abstractions like NestJS paired with ORMs like Prisma promise rapid development and end-to-end type safety, while lightweight runtimes and raw SQL prioritize execution speed and minimal resource overhead.

To evaluate these trade-offs with empirical data, I implemented the exact same production-grade domain logic—a Fact-Checked News Platform & API—across three distinct tech stacks and benchmarked their response latencies under identical infrastructure conditions.

Environment & Infrastructure Specifications

All three applications were deployed in production mode on the same isolated Virtual Private Server (VPS) instance:

• CPU: 2 vCPU
• RAM: 8 GB
• Storage: 100 GB NVMe SSD
• OS / Host Environment: Linux / Docker containers behind Nginx

> Disclaimer: These results represent baseline response latency benchmarks (Time To First Byte + query execution) measured under standard server conditions using a single-vNode monitor. They are intended as an exploratory comparison of runtime overhead and data abstraction layers rather than a full synthetic load or stress test.

Tech Stacks & Architectural Strategy

1. Go + PostgreSQL (pgvector)

• Native compiled backend utilizing pgvector for semantic search and native database/sql connection pooling.

2. Node.js + Express (TypeScript) + MySQL (Raw SQL)

• Lightweight Express routing written in TypeScript, executing optimized raw parameterized SQL queries via native drivers.

3. Node.js + NestJS (TypeScript) + MySQL (Prisma ORM)

• Modular architecture using NestJS dependency injection paired with Prisma object-relational mapping.

Benchmark Results

Using a custom-built latency monitor (goChecker), I measured real-time server response times across all three endpoints running on the VPS environment:

| Backend Implementation | Stack & Data Layer Strategy | Real-Time Latency

| Performance Ratio | | --- | --- | --- | --- | | stiri.digital | Go + PostgreSQL (pgvector) | 23 ms | Baseline (1.0x) | | news-express | Node.js + Express (TypeScript) + Raw MySQL | 45 ms | ~2.0x slower | | news-nest | Node.js + NestJS (TypeScript) + Prisma ORM | 278 ms | ~12.1x slower |

Architectural Deep Dive: What Explains the Delta?

1. Go + PostgreSQL (23 ms) — Native Concurrency & Low Overhead

• Compiled Execution: Go compiles directly to machine code, eliminating dynamic runtime checks, event-loop context switching, and virtual machine startup costs.
• Driver & Memory Efficiency: Go’s SQL driver manages connection pooling with a negligible memory footprint, keeping request execution fast even on a 2-CPU VM.
• Vector Execution at DB Layer: Vector calculations using pgvector run directly inside PostgreSQL's C implementation rather than marshaling vector data into application memory.

2. Express + TypeScript + Raw SQL (45 ms) — Zero Runtime Abstraction Bloat

• Compile-Time Safety Only: Since TypeScript types are erased during build time, Express executes as lean JavaScript with static type guarantees without any runtime performance penalty.
• Direct SQL Streaming: Skipping ORM object instantiation allows raw query results to stream directly into the JSON response payload.
• Minimal Pipeline Overhead: Express provides a thin routing layer, avoiding heavy metadata reflection or complex dependency injection resolution per request.

3. NestJS + TypeScript + Prisma (278 ms) — The Price of High Abstraction

While NestJS and Prisma offer top-tier developer ergonomics and type safety, the ~12x latency delta highlights key architectural trade-offs:

• Prisma Query Engine Overhead: Prisma’s Rust-based binary engine translates schema calls into SQL, executes them, and parses relational responses into complex TypeScript entities, introducing measurable serialization delay.
• NestJS Pipeline & Reflection: Every request passes through a multi-layered middleware pipeline involving metadata reflection (reflect-metadata), dependency injection, guards, pipes, and interceptors.
• Implicit Query Patterns: Relational queries resolved via Prisma can trigger sub-optimal query patterns or sequential queries compared to a hand-crafted SQL JOIN.

Key Engineering Takeaways

1. TypeScript is not the bottleneck: Both Express and NestJS were written in TypeScript, yet Express delivered response times close to native Go (~45 ms vs. 23 ms). TypeScript adds zero runtime overhead; performance costs stem from framework reflection and ORM abstractions.

2. ORMs trade runtime speed for developer productivity: ORMs like Prisma excel at schema management and rapid feature delivery, but raw SQL remains superior for tight response latency SLAs.

3. Right tool for the right job:

• NestJS + Prisma: Ideal for rapid MVP development, complex enterprise backends, and team environments requiring strict architectural conventions.
• Go or Express (TypeScript) + Raw SQL: Excellent for core microservices, high-traffic APIs, and latency-sensitive production systems operating on modest hardware allocations.