memory-store
is used. This one does not synchronize it’s state across instances. It’s simple
to deploy, and often sufficient for basic abuse prevention, but will be
inconnsistent across reboots or in deployments with multiple process or servers.
Deployments requiring more consistently enforced rate limits should use an
external store.
Here is a list of known stores:
Name | Description | Legacy/Modern API |
---|---|---|
memory-store | (default) Simple in-memory option. Does not share state when app has multiple processes or servers. | Modern as of v6.0.0 |
cluster-memory-store | A memory-store wrapper that shares state across all processes on a single server via the node:cluster module. Does not share state across multiple servers. | Modern |
rate-limit-redis | A Redis-backed store, more suitable for large or demanding deployments. | Modern as of v3.0.0 |
rate-limit-memcached | A Memcached-backed store. | Modern as of v1.0.0 |
rate-limit-mongo | A MongoDB-backed store. | Legacy |
precise-memory-rate-limit | A memory store similar to the built-in one, except that it stores a distinct timestamp for each key. | Modern as of v2.0.0 |
rate-limit-postgresql | A PostgreSQL-backed store. | Modern |
typeorm-rate-limit-store | Supports a variety of databases via TypeORM: MySQL, MariaDB, CockroachDB, SQLite, Microsoft SQL Server, Oracle, SAP Hana, and more. | Modern |