Introduction
OutlabsTaskq (outlabs-taskq) is a Postgres-native task queue for Python fleets.
It is infrastructure extracted from production systems at OutLabs — the same class of problem as outlabs-auth: stop reinventing a foundational backend piece in every product.
Why it exists
Most teams either:
- Run Redis / RabbitMQ / Celery and accept another operational dependency, or
- Grow an ad-hoc
jobstable until claim races, lost settles, and silent duplicates show up at 2am.
OutlabsTaskq takes a third path: PostgreSQL is the broker, and the PL/pgSQL functions are the contract. The Python package is a typed client — not a second source of truth.
What you get today (0.1.0a2)
SQL kernel
Schema taskq, three packaged migrations, capability roles, and taskq migrate / taskq verify.
Typed client
Task + TaskRegistry + TaskQ.enqueue with created / existed results — never silent null.
Worker + CLI
Fenced claims, heartbeats, settle mapping, soft stop, and taskq worker.
Optional HTTP
Mount create_taskq_app for credential-free workers. Auth is injected; outlabs-auth is optional.
Status
Pre-alpha (0.1.0a2). Stages 1–3 are independently accepted and ship in the package: SQL kernel, typed client/worker/CLI, consumer testing helpers, Protocol-v1 HTTP clients and facade, authorization boundary, and optional OutLabs authorizer/provisioning.
Stage 4 (first-host dogfood on outlabsAPI) is open — usable for local and staging adoption, with the production canary still gated.
Related OutLabs infrastructure
| Package | Role |
|---|---|
outlabs-auth | Identity / RBAC / API keys for FastAPI |
outlabs-taskq | Job queue / worker coordination on Postgres |