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 builder call differs.

Unlike a Celery/RabbitMQ setup, there's no separate broker (message-routing middleman process) to run: the scheduler lives inside the worker process and reads/writes the backend directly. SQLite and Postgres need nothing beyond a database. Redis still requires a Redis instance when you select it, but it's used directly as the queue's data store rather than as a separate broker.

java

FlexiQ.builder().open();                                    // SQLite at .flexiq/flexiq.db (default)
FlexiQ.builder().sqlite("/var/lib/app/flexiq.db").open();  // SQLite, explicit path
FlexiQ.builder().postgres(System.getenv("PG_URL")).schema("flexiq").open();
FlexiQ.builder().redis("redis://localhost").prefix("flexiq").open();

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.

backend(name) + url(dsn) are the generic forms behind the shortcuts; poolSize(int) sizes the connection pool and namespace(String) isolates one application's jobs in a shared store. All three backends ship in the published native library — no extra build step.

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.