Rate Limiter Comparison
How does hitlimit compare to other popular rate limiting libraries? This guide provides an honest comparison to help you choose the right tool.
Quick Comparison
| Feature | hitlimit | express-rate-limit | @fastify/rate-limit | rate-limiter-flexible | @nestjs/throttler |
|---|---|---|---|---|---|
| Zero Dependencies | Yes | 1 dep | 3 deps | Yes | Peer only |
| TypeScript | Native | Native | Native | Native | Native |
| Memory Store (high-traffic) | 4.08M ops/s | 824K ops/s | N/A | 1.26M ops/s | N/A |
| SQLite Store | Built-in | External | No | No | No |
| Redis Store | Built-in | External | Built-in | Built-in | External |
| Valkey Store | Built-in | No | No | No | No |
| DragonflyDB Store | Built-in | No | No | No | No |
| Postgres Store | Built-in | No | No | Built-in | No |
| Human-readable Windows | '1m', '1h' | ms only | '1 minute' | seconds | ms (+ helpers) |
| Tiered Limits | Built-in | Manual | Via dynamic max | Manual | Manual |
hitlimit vs express-rate-limit
express-rate-limit is the most popular rate limiter with 3M+ weekly downloads. It's a solid choice for basic Express rate limiting.
Choose hitlimit if you need:
- Better high-traffic performance (2x faster with many unique IPs)
- Built-in SQLite support for persistence
- Human-readable time windows (
'1m'vs60000) - Multi-framework support (Express, Fastify, NestJS, Hono, Bun)
- Built-in tiered limits for SaaS
Choose express-rate-limit if you need:
- Battle-tested library with massive community
- Extensive documentation and examples
- Wide variety of external stores
Migration from express-rate-limit
import rateLimit from 'express-rate-limit'
const limiter = rateLimit({
windowMs: 60000, // 1 minute in ms
max: 100,
standardHeaders: true,
legacyHeaders: false
}) import { hitlimit } from '@joint-ops/hitlimit'
const limiter = hitlimit({
limit: 100,
window: '1m' // Human-readable!
}) hitlimit vs rate-limiter-flexible
rate-limiter-flexible is a feature-rich library with support for many backends. It's great for complex rate limiting scenarios.
Choose hitlimit if you need:
- Simpler API with less configuration
- Built-in framework adapters (Express, Fastify, NestJS, Hono, Elysia, Bun.serve)
- Built-in SQLite store
- Native Bun support
Choose rate-limiter-flexible if you need:
- PostgreSQL, MySQL, MongoDB, DynamoDB, or Memcached backends (14 stores total)
- Cluster mode support
- Insurance limiter (fallback when store fails)
- Weighted/points-based rate limiting
hitlimit vs @nestjs/throttler
@nestjs/throttler is the official NestJS rate limiting module. It integrates deeply with NestJS decorators and DI system.
Choose hitlimit if you need:
- Built-in SQLite and Redis stores
- Use same library across Express, NestJS, and Bun
- Human-readable time windows
- Built-in tiered limits for SaaS
Choose @nestjs/throttler if you need:
- Deep NestJS integration with decorators
- Official Nest team support
- Guard-based approach with per-route configuration
- Named throttler groups (short/medium/long)
Migration from @nestjs/throttler
import { ThrottlerModule } from '@nestjs/throttler'
@Module({
imports: [
ThrottlerModule.forRoot([{
ttl: 60000,
limit: 100
}])
]
}) import { HitlimitModule } from '@joint-ops/hitlimit/nest'
@Module({
imports: [
HitlimitModule.register({
limit: 100,
window: '1m'
})
]
}) hitlimit vs @fastify/rate-limit
@fastify/rate-limit is the official Fastify rate limiter plugin maintained by the Fastify team. It's the default choice for Fastify-only projects.
Choose hitlimit if you need:
- Auto-ban after threshold violations
- Shared rate limits via groupId
- Built-in tiered rate limits (Free/Pro/Enterprise tiers in 8 lines)
- Per-request error handling (
onStoreErrorcallback) - Built-in SQLite store for persistence without Redis
- Same library across Express, Fastify, NestJS, and Bun
- Zero runtime dependencies
Choose @fastify/rate-limit if you need:
- Official Fastify team maintenance and support
- IP allowList built-in
- Fastify-only project (tighter integration)
Migration from @fastify/rate-limit
import rateLimit from '@fastify/rate-limit'
await app.register(rateLimit, {
max: 100,
timeWindow: '1 minute'
}) import { hitlimit } from '@joint-ops/hitlimit/fastify'
await app.register(hitlimit, {
limit: 100,
window: '1m'
}) Performance Comparison
High-traffic scenario (10,000 unique IPs) - where hitlimit excels.
Memory store, 10k unique keys. hitlimit is also fastest on single-IP (5.96M vs 2.06M for rate-limiter-flexible). hitlimit also supports MongoDB, Redis, Postgres, and other distributed stores for multi-server deployments. These are our benchmarks — we've done our best to keep them fair and reproducible. See full benchmarks or clone and run them yourself.
Feature Overview
hitlimit-bun is the only dedicated rate limiting library built for the Bun runtime. Here's what you get out of the box.
| Feature | hitlimit-bun |
|---|---|
| Bundle Size | ~18KB |
| Zero Dependencies | Yes |
| TypeScript | Native |
| Memory Store | 5.57M ops/s (10K IPs) |
| bun:sqlite Store | Built-in (native, 0 deps) |
| Redis Store | Built-in (Lua scripts) |
| Valkey Store | Built-in (Redis alternative) |
| DragonflyDB Store | Built-in (high-throughput) |
| Postgres Store | Built-in |
| Bun.serve | Native adapter |
| Elysia | Native plugin |
| Hono | Native middleware |
| Human-readable Windows | '1m', '1h' |
| Tiered Limits | Built-in |
hitlimit-bun vs hono-rate-limiter
hono-rate-limiter is a community-maintained rate limiter for Hono (rhinobase/hono-rate-limiter). It works on Bun via Hono, but isn't Bun-native.
Choose hitlimit-bun if you need:
- Zero runtime dependencies — no external packages needed
- Native bun:sqlite — Zero-dependency persistence at 372K ops/sec
- Multiple frameworks — Bun.serve, Elysia, and Hono from one package
- Human-readable time windows —
'1m'vs milliseconds - Built-in tiered limits — Free/Pro/Enterprise tiers in 8 lines
- Built-in Redis store — Atomic Lua scripts, no separate package
- Zero runtime dependencies
Choose hono-rate-limiter if you need:
- Cloudflare KV store support (via separate package)
- Familiar express-rate-limit-like API
- Community-driven development
Migration from hono-rate-limiter
import { rateLimiter } from 'hono-rate-limiter'
app.use(rateLimiter({
windowMs: 60000, // milliseconds
limit: 100,
keyGenerator: (c) => c.req.header('x-api-key')
})) import { hitlimit } from '@joint-ops/hitlimit-bun/hono'
app.use(hitlimit({
window: '1m', // human-readable!
limit: 100,
key: (c) => c.req.header('x-api-key') || 'anonymous'
})) Store Performance
Every store is optimized for its use case. In-process stores offer raw speed; distributed stores trade latency for shared state across instances.
In-Process Stores
Zero network overhead — data lives in the same process.
Distributed Stores
Shared state across multiple server instances.
Bun significantly outperforms Node.js at 10K IPs (5.57M vs 4.08M) and single-IP (7.73M vs 5.96M). These are our benchmarks — we've done our best to keep them fair. They're not set in stone; there's always room for improvement. See full benchmarks or clone and run them yourself.
Why hitlimit?
Key advantages that set hitlimit apart:
Human-readable time windows
'15m' instead of 900000 milliseconds
Built-in tiered limits
Free/Pro/Enterprise tiers without manual routing
Per-request error handling
onStoreError callback for granular control
Zero dependencies
No runtime dependencies for the core module
Native Bun support
bun:sqlite as default store for persistence
Multi-framework
Same API across Express, NestJS, Bun, Elysia
When to Use Each
| Use Case | Recommendation |
|---|---|
| New Express/Node.js project | hitlimit - Fast, clean API |
| SaaS with tiered limits | hitlimit - Built-in tier support |
| Zero dependencies matters | hitlimit - Zero runtime deps |
| New Fastify project | hitlimit - Tiered limits + multi-framework |
| Fastify-only, need allowList | @fastify/rate-limit - Official plugin |
| PostgreSQL/MySQL/MongoDB backend | rate-limiter-flexible - More database options |
| Deep NestJS decorators | @nestjs/throttler - Official Nest module |
| Maximum community support | express-rate-limit - 3M+ weekly downloads |
Use hitlimit for
- New projects (Node.js or Bun)
- Performance-critical APIs
- Multi-framework consistency
- SQLite-based persistence
- SaaS tiered rate limits
Use express-rate-limit for
- Existing Express projects
- Need specific external stores
- Maximum community support
Use rate-limiter-flexible for
- 14 storage backends
- Weighted/points-based limits
- Insurance/fallback patterns
Use @nestjs/throttler for
- Deep NestJS integration
- Decorator-based approach
- Official Nest support
When to Use hitlimit-bun
| Use Case | Store |
|---|---|
| Single server, maximum speed | Memory (default) — 5.57M ops/sec |
| Need persistence, single server | bun:sqlite — 372K ops/sec, 0 deps |
| Multi-server / distributed | Redis — Network-bound, Lua scripts |
| Multi-server / open-source | Valkey — BSD-licensed Redis alternative |
| Multi-server / high-throughput | DragonflyDB — multi-threaded |
| Multi-server / distributed (SQL) | Postgres — Network-bound |
| Elysia plugin | Any store — native plugin API |
| Hono middleware | Any store — native middleware |
| SaaS with tiered limits | Any store — built-in tier support |
Get Started
Ready to try hitlimit?
npm install @joint-ops/hitlimit Get Started
Ready to try hitlimit-bun?
bun add @joint-ops/hitlimit-bun