BullMQ.Backends.Postgres (BullMQ v2.0.2)

View Source

PostgreSQL implementation of the BullMQ.Backend behaviour — the Elixir port of the Node.js PostgresQueueBackend.

The heavy lifting lives in language-agnostic SQL: the schema and PL/pgSQL operation functions are applied by BullMQ.Backends.Postgres.Migrator from the shared src/postgres/migrations/*.sql, and every runtime operation runs a parameterized statement from src/postgres/commands/*.sql (loaded by BullMQ.Backends.Postgres.SqlLoader). This adapter only builds the parameter lists and maps result rows into the same shapes the high-level BullMQ modules already consume from the Redis backend.

The connection-level schema is the namespace for all queues (the SQL-native replacement for Redis's per-queue key prefix), so the .sql files reference unqualified names and stay portable.

Usage

{:ok, _} = BullMQ.Backends.Postgres.Connection.start_link(
  name: :pg, url: "postgres://localhost/bullmq", schema: "bullmq")

# Point BullMQ at the Postgres backend, then use Queue/Worker as usual:
{:ok, _} = BullMQ.Queue.add("emails", "welcome", %{},
  connection: :pg, backend: BullMQ.Backends.Postgres)

Summary

Types

t()

A Postgres backend instance.

Functions

Builds a Postgres backend for the queue name.

Types

t()

@type t() :: %BullMQ.Backends.Postgres{
  connection: atom(),
  notifications: term(),
  owns_connection: boolean(),
  pool: term(),
  queue_name: String.t(),
  schema: String.t()
}

A Postgres backend instance.

Functions

minimum_block_timeout()

new(name, opts)

@spec new(
  String.t(),
  keyword()
) :: t()

Builds a Postgres backend for the queue name.

Options