Backends

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.

There's no separate broker (message-routing middleman process) to run — SQLite needs nothing beyond a file, Postgres nothing beyond a database, and Redis is one backend of three here, not a 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.

Push-dispatch's wake channel is scoped by prefix, namespace and queue, not by Redis database number. Two deployments on the same server with the same prefix and namespace but different SELECTed databases will cross-wake each other — harmless (a spurious empty dequeue), but worth a distinct prefix per deployment.