On this page

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' vs 60000)
  • 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

Before (express-rate-limit)
import rateLimit from 'express-rate-limit'

const limiter = rateLimit({
  windowMs: 60000,  // 1 minute in ms
  max: 100,
  standardHeaders: true,
  legacyHeaders: false
})
After (hitlimit)
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

Before (@nestjs/throttler)
import { ThrottlerModule } from '@nestjs/throttler'

@Module({
  imports: [
    ThrottlerModule.forRoot([{
      ttl: 60000,
      limit: 100
    }])
  ]
})
After (hitlimit)
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 (onStoreError callback)
  • 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

Before (@fastify/rate-limit)
import rateLimit from '@fastify/rate-limit'

await app.register(rateLimit, {
  max: 100,
  timeWindow: '1 minute'
})
After (hitlimit)
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.

hitlimit 4.08M ops/s
rate-limiter-flexible 1.26M ops/s
express-rate-limit 824K ops/s

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

Before (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')
}))
After (hitlimit-bun)
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.

bun:sqlite Store
372K ops/s
~2.7μs latency
Persistent, survives restarts

Distributed Stores

Shared state across multiple server instances.

Redis Store
Network-bound ops/s
Network-bound latency
Multi-instance, dedicated cache
Valkey Store
Network-bound ops/s
Network-bound latency
Open-source Redis alternative (BSD)
DragonflyDB Store
Network-bound ops/s
Network-bound latency
Multi-threaded, parallel Lua
Postgres Store
Network-bound ops/s
Network-bound latency
Use your existing database

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