On this page

Memory Store

The memory store is the default storage backend. It keeps rate limit data in memory, making it the fastest option available.

Usage

The memory store is used by default when no store is specified:

import { hitlimit } from '@joint-ops/hitlimit'

// Memory store is the default
app.use(hitlimit({ limit: 100, window: '1m' }))
import { hitlimit } from '@joint-ops/hitlimit-bun'

// Memory store is the default
const limiter = hitlimit({ limit: 100, window: '1m' })

Or explicitly configure it:

import { hitlimit, memoryStore } from '@joint-ops/hitlimit'

app.use(hitlimit({
  limit: 100,
  window: '1m',
  store: memoryStore({
    cleanupInterval: 60000  // Clean expired entries every 60s
  })
}))
import { hitlimit, memoryStore } from '@joint-ops/hitlimit-bun'

const limiter = hitlimit({
  limit: 100,
  window: '1m',
  store: memoryStore()  // No options needed — Bun handles cleanup internally
})

Options

OptionTypeDefaultDescription
cleanupIntervalnumber60000Interval (ms) to clean expired entries

Characteristics

  • Speed: Fastest option — 5.96M ops/sec peak, no I/O overhead
  • Persistence: Data is lost on restart
  • Scalability: Not shared between instances
  • Memory: Grows with unique keys; auto-cleanup removes expired entries
  • Speed: 7.73M ops/sec (~129ns latency) — the fastest store available
  • Zero dependencies: Built into the runtime
  • Persistence: None — data is lost on restart
  • Scalability: Single instance only — not shared between processes
  • Memory: Grows with unique keys; auto-cleanup via internal sweep timer

When to Use

  • Development and testing environments
  • Single-instance deployments
  • When persistence across restarts is not required
  • Maximum throughput applications where every nanosecond counts

Limitations

  • Rate limits reset on server restart
  • Not suitable for multi-server or distributed deployments — use Redis instead
  • Memory usage increases with the number of unique client keys