Background jobs that live with your data

AWA is a Postgres-native job queue for Rust and Python. Enqueue work in the same transaction as your application data, then run durable workers with retries, scheduling, progress, callbacks, and crash recovery.

Start with Rust Start with Python

One system of record

Business data and job state share PostgreSQL. A transaction either commits both the application change and its follow-up work, or neither. Workers claim runnable rows without a separate broker, keep active claims alive, and leave enough state behind for another worker to recover work after a crash.

Transactional by design Commit an application write and its background job atomically. Durable execution Persist attempts, retries, schedules, callback waits, and progress. Operable in production Inspect queues with the CLI, web UI, metrics, traces, and SQL.

Pick the interface that fits your service

RustPythonOperations

cargo add awa@0.6.6

Define typed job arguments, register async handlers, and use your existing sqlx pool for migrations, enqueueing, and administration.

Build a Rust worker →

uv add awa-pg==0.6.6

Register sync or async handlers around dataclasses and use direct clients or transaction bridges for asyncpg, psycopg, SQLAlchemy, and Django.

Build a Python worker →

uv tool install awa-cli==0.6.6
awa --database-url "$DATABASE_URL" health

Run migrations, inspect jobs and queues, administer the dead-letter queue, and serve the optional web dashboard.

Explore the CLI →

Understand the boundaries

AWA provides at-least-once delivery: a handler may run more than once when a worker loses its claim or its completion write cannot be confirmed. Handlers should therefore be idempotent, or make their side effects transactional.

Start with how AWA works, then use the deployment, security, and troubleshooting guides before production.