Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/msolli/proletarian/llms.txt

Use this file to discover all available pages before exploring further.

Proletarian is a durable job queuing and worker system for Clojure backed by PostgreSQL 9.5+ or MySQL 8.0.1+. It is designed for teams that need to reliably offload long-running or side-effectful work — sending emails, calling external APIs, updating search indexes, running batch imports — away from the request thread, without introducing a separate message broker or infrastructure component.

No Extra Infrastructure Required

If you are already running PostgreSQL or MySQL as your main database, Proletarian requires nothing more. Your job queue lives in the same database your application already talks to. No Redis, no RabbitMQ, no Kafka — just the Postgres or MySQL instance you already operate and monitor.

Transactional Enqueueing (the Outbox Pattern)

The most powerful feature of a database-backed job queue is the ability to enqueue a job and commit application data in a single transaction. Consider the classic example: a user signs up, you write their account to the database, and you want to send them a confirmation email. If you enqueue the email job outside the transaction, you risk a crash between the commit and the enqueue — the account is saved but the email is never sent. With Proletarian you wrap both operations in one jdbc/with-transaction block. Either both succeed or neither does. This pattern is known in distributed systems literature as the Outbox Pattern.
(jdbc/with-transaction [tx db]
  (create-account! tx user)
  (job/enqueue! tx ::send-confirmation-email {:email (:email user)}))

At-Least-Once Delivery

Proletarian uses PostgreSQL/MySQL transactions internally when polling and running jobs. A job is not removed from the queue until it has finished successfully — it is moved to the archive table atomically in the same transaction. This guarantees that every job runs at least once, even in the face of database failures, network errors, or process crashes.
Because jobs may execute more than once in rare failure scenarios, your job handlers should be idempotent — running them multiple times must produce the same result. Design your handlers to be safe to re-run, or ensure your business rules can tolerate the occasional duplicate execution.

Feature Highlights

PostgreSQL & MySQL

Works with PostgreSQL 9.5+ and MySQL 8.0.1+. Uses your existing database — no separate broker needed.

Transactional Enqueueing

Atomically enqueue jobs alongside your database writes in a single transaction using the Outbox Pattern.

At-Least-Once Delivery

Jobs are never silently dropped. Proletarian’s transaction-backed polling guarantees every job is executed.

Configurable Retries

Define per-job retry strategies with custom attempt counts and back-off delays. Failed jobs land in the archive table.

Multiple Queues

Run as many queue workers as you like against different named queues — each with its own thread count and polling interval.

Graceful Shutdown

worker/stop! drains in-flight jobs before shutting down. Optional JVM shutdown hook support is built in.

Typical Use Cases

Proletarian is a great fit for any task that is too slow or too risky to execute on the request thread:
  • Sending emails — transactionally enqueue the job when the triggering event is committed to the database.
  • HTTP calls to external systems — isolate third-party latency and failures from your web request cycle.
  • Search index updates — batch up or fan out writes to Elasticsearch, Typesense, or similar.
  • Batch imports and exports — process large datasets in the background without blocking users.

Get Started

Installation

Add the dependency and create the required database tables.

Quickstart

Define a handler, start a worker, and enqueue your first job in five minutes.

Build docs developers (and LLMs) love