Backends
SQLite, PostgreSQL, or Redis — same API, different storage.
SQLite, PostgreSQL, or Redis — same API, different storage.
The queue stores everything — jobs, results, schedules, locks, rate-limit state — in one backend. The API is identical across all three; only the constructor differs.
Unlike BullMQ, there's no separate broker (message-routing middleman process) to run — SQLite and Postgres need nothing beyond a database, and even the Redis backend is just a data store here, not a required dependency of the queue itself. Start on SQLite with zero infrastructure and move to Postgres or Redis later without changing task code.
new Queue({ dbPath: "flexiq.db" }); // SQLite (default)
new Queue({ backend: "postgres", dsn: process.env.PG_URL, schema: "flexiq" });
new Queue({ backend: "redis", dsn: "redis://localhost", prefix: "flexiq" });| Backend | Use when | Notes |
|---|---|---|
| SQLite | Single host, simplest deploy | One file, WAL (write-ahead log) mode, no server. Bundled. |
| PostgreSQL | Multiple hosts, durability | SELECT ... FOR UPDATE SKIP LOCKED dispatch; isolated schema. |
| Redis | High throughput, ephemeral OK | JSON values + sorted sets; atomic Lua claims. |
Postgres and Redis require the addon built with their cargo features —
build:native enables --features postgres,redis, and the published prebuilt
binaries include them.
Producers and workers must point at the same backend. SQLite is per-host (shared file); Postgres/Redis let producers and workers run on different machines against one shared store.