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.