Jobs & Queues Overview
FoundryDB gives app services two primitives for background work: Jobs and Queues. Both run inside your service's infrastructure, colocated with your data, so you do not pay for separate workers or accept extra network hops.
Jobs
A job is a container invocation that runs on your app service's VM. You define a name, the command to run, and optionally a cron schedule. The platform dispatches each fire as a transient systemd unit: resource-isolated, observable, and logged independently of your main application container.
Jobs are well suited for:
- Scheduled batch processing (nightly reports, daily aggregates, periodic cleanup)
- One-shot tasks triggered from CI or an API call (database migrations, data backups, ad-hoc scripts)
- Any work that must run close to the database but does not need to stay resident
| Feature | Detail |
|---|---|
| Trigger types | Cron schedule, on-demand via API |
| Concurrency | Per-job cap (1 to 5 simultaneous invocations) |
| Runtime limit | 10 seconds to 6 hours |
| Retries | 0 to 5 attempts with configurable backoff |
| Overlap policy | skip (a cron fire that finds the cap full is recorded and skipped) |
| Log retention | Last 40 lines stored on the invocation; full logs retrievable on demand |
| Limit | 20 jobs per app service |
Queues
A queue is a durable, PostgreSQL-backed message queue provisioned inside one of your PostgreSQL managed services. Messages live in the mdb_queue schema, transactional with your application data. Consumers claim messages with SELECT ... FOR UPDATE SKIP LOCKED so concurrent workers never race or double-process.
Queues are well suited for:
- Decoupling producers from consumers within your application
- Reliable task dispatch where enqueue must be atomic with a business write
- Work that needs at-least-once delivery and a dead-letter audit trail
| Feature | Detail |
|---|---|
| Backend | PostgreSQL mdb_queue schema, SKIP LOCKED |
| Delivery | At-least-once |
| Batch enqueue | Up to 100 messages per request |
| Message size | Up to 256 KB per message |
| Visibility timeout | Configurable per queue, up to 12 hours |
| Retries | Configurable max_attempts, dead-letter queue on exhaustion |
| Limit | 50 queues per PostgreSQL service |
When to use each
| Situation | Use |
|---|---|
| Run a script every night at 02:00 | Job with cron schedule |
| Trigger a migration from your deployment pipeline | Job, invoke via /run |
| Fan out work from a web request to background workers | Queue |
| Audit every unit of work that succeeded, failed, or was retried | Queue with DLQ |
| Keep background work transactional with your business data | Queue (enqueue in the same transaction as the write) |
How they relate
Jobs and queues are independent features. A common pattern is to combine them: a job fires on a schedule, reads from a queue, and processes a batch. The queue carries the durable work; the job drives the processing cadence.
Both features are scoped to a service in your FoundryDB organization. Jobs are scoped to an app service; queues are scoped to a PostgreSQL managed service.