NestJS Rate Limiting: In-Memory vs Redis vs Postgres

Cross-posted from my blog. The full article, with any updates, lives on fabwaseem.com. I tested the rate limiting features in NestJS 12 using three different storage backends: in-memory, Redis, and PostgreSQL. All tests were conducted on an 8 vCPU/16 GB Linux VM on November 6, 2026, using Node.js 24.22.1, NestJS 12.3.3, and @nestjs/throttler 6.7.1.

Redis 7.2.11 (without persistence) was used for Redis storage, and PostgreSQL 18.6 was used for PostgreSQL storage. The limit for all tests was set to 100 requests per 60 seconds, with the tracker keyed on the x-forwarded-for header to ensure localhost tests did not share the same IP. The three metrics measured were the p50 and p95 latency of allowed requests, whether request 101 returns a 429 response, and whether two Nest processes using the same storage still stop at 100 total requests.

The in-memory storage is the default setup, which is sufficient for a single process but fails to provide accurate rate limiting when scaled out across multiple processes. For Redis storage, the @nestjs-redis/throttler-storage package was used, which implements the ThrottlerStorage interface with an atomic Lua script to increment the counter.

PostgreSQL storage was implemented as a custom storage solution, where each key is stored in a throttler_hits table with hits, expires_at, is_blocked, and block_expires_at columns. In all tests, the limit was set to 100 requests per 60 seconds, and the x-forwarded-for header was used as the tracker to ensure accurate rate limiting across multiple instances.