Why another queue?​

Most Node queues assume Redis. That's a great fit for some teams and an unwanted extra moving part for many others — a second datastore to run, secure, back up, and reason about. Meanwhile, PostgreSQL with SKIP LOCKED and LISTEN/NOTIFY is more than enough for a robust queue, as pg-boss showed. PortQueue takes that insight and makes it multi-driver, strictly typed, and transactional.

What you get​

• One API across every engine. Swap the driver import; your app code is unchanged.
• One process or many. One pq object produces and consumes, so running everything on a single server is a complete setup — and splitting producers from consumers is there when you want it.
• Transactional enqueue. A job exists only if your business transaction commits — the dual-write bug, gone.
• Operational maturity. Retries with backoff, rate limiting, backpressure, cron with timezones, a dashboard, and a CLI — no third-party service.

A first taste​

import { PortQueue } from '@portqueue/core';
import { PostgresqlDriver } from '@portqueue/core/drivers/postgresql';

const pq = new PortQueue({ driver: new PostgresqlDriver({ connectionString: process.env.DATABASE_URL }) });
await pq.init();

// Create the queue and provide a jobs handler.
pq.createQueue({
  name: 'emails',
  limiter: { concurrency: 10 },
  handler: async (job) => { await send(job.data); },
});

// Add a job to the queue.
await pq.addJob({ queue: 'emails', data: { to: 'a@b.com' } });

Free and open source. Commercial use permitted. No license fee, no obligations.

Head to Getting Started to try it.

The hidden cost of a second datastore​

A Redis-backed queue is fast, but it's another system to run, secure, monitor, back up, and keep consistent with your primary database. And the moment you want "enqueue this job only if the order row commits," a separate datastore turns into a distributed-systems problem — the classic dual-write bug.

When DB-backed wins​

• You already operate a relational database and don't want a broker.
• You need transactional enqueue — the job and the business write commit together.
• You want jobs to be queryable with SQL and visible in a dashboard without a separate result backend.
• You ship to customers on different databases and want one codebase.

What we kept broker-like​

Low latency still matters, so where the engine supports it (PostgreSQL) workers wake within milliseconds via LISTEN/NOTIFY; elsewhere they poll on a tunable interval. You get broker-like responsiveness without the broker.

Read how it scales horizontally, or start with Getting Started.

What makes PortQueue different​

• Great for distributed instances. Any number of workers, on any number of servers, claim from the same queue with SKIP LOCKED and never double-process. Multi-instance mode is a one-line opt-in.
• Truly multi-driver — same code, different engines. The same application code runs unchanged on PostgreSQL, MySQL, Oracle, PGLite, and SQLite. You swap the driver, not your code.
• Easy to test. Run your entire suite in-process against PGLite or SQLite — no Redis, no broker, no external database to stand up.
• Fault tolerant. Visibility timeouts, retries with backoff, and stalled-job recovery mean an instance can crash mid-job without losing work.

Where each shines​

• pg-boss — a great, focused PostgreSQL queue. If you're PostgreSQL-only and happy with its API, it's excellent. PortQueue generalizes the idea to many engines — the same code runs on seven of them — with richer results and in-process testing.
• BullMQ — the gold standard on Redis, with a clean producer/consumer split we admire and adopted. If Redis is already core to your stack, it's a strong choice. PortQueue trades Redis for your existing database and swaps numeric progress for resumable steps.
• Celery — battle-tested operational maturity in the Python world (retries, rate limits, beat, visibility timeouts). PortQueue brings that maturity to typed Node.js and keeps results in the same database.

Why the differences matter​

If you want transactional enqueue or must run on a customer-chosen database, the broker-based options can't help cleanly. That's the gap PortQueue fills.

See Getting Started to try it.

The fix: join the developer's transaction​

PortQueue lets the job insert run inside your own transaction. The job exists iff your business write commits, and the NOTIFY that wakes workers fires only after commit.

import { fromKnex } from '@portqueue/core/tx';

await knex.transaction(async (trx) => {
  await trx('order').insert(order);
  await pq.addJob({ queue: 'fulfillment', data: { orderId }, tx: fromKnex(trx) });
}); // your trx owns commit/rollback

Why PortQueue never owns the transaction​

There is no pq.transaction(fn) and no adoptTransaction. You start the transaction with your ORM or query-builder, wrap it with a small adapter (fromKnex, fromPg, fromPrisma, fromDrizzle, …), and pass it as tx. Keeping ownership in your code means the queue never surprises you by committing early or holding a connection.

Read the full Transactions guide.