Relyt ONE ships with PGMQ v1.7 enabled for every Postgres cluster, so you can run durable message queues directly in Postgres. Use simple SQL to send, receive, delete, and archive jobs without leaving the database.Documentation Index
Fetch the complete documentation index at: https://docs-relytone.data.cloud/llms.txt
Use this file to discover all available pages before exploring further.
Key Capabilities
- Visibility timeouts keep a message locked to one consumer before it reappears
- SQL-first workflow—no background workers or extra services to manage
- Archive or delete messages to match compliance or replay needs
- Pure Postgres deployment with the extension already managed by Relyt ONE
Quick Start
Step 1: Enable the extension
Step 2: Create a queue
pgmq schema (q_<queue_name>). Archives live under a_<queue_name>.
Step 3: Publish messages
pgmq.send_batch with a JSONB array to enqueue many messages atomically.
Step 4: Consume messages
pgmq.pop('my_queue') is a shortcut that reads and deletes a single message immediately.
Step 5: Complete work
- Delete forever:
SELECT pgmq.delete('my_queue', msg_id); - Archive for replay:
SELECT pgmq.archive(queue_name => 'my_queue', msg_id => 7); - Inspect archives via
SELECT * FROM pgmq.a_my_queue;
Step 6: Clean up
Visibility Timeout Tips
- Set
vtlonger than the expected processing time; unfinished work reappears when the timeout expires. - Use shorter
vtfor idempotent consumers needing faster retries. - Always delete or archive after successful processing to avoid duplicates.
Best Practices
- Keep messages small—store big payloads in tables and enqueue references.
- Monitor lag by counting rows in
pgmq.q_*tables or usingread_ct. - Standardize headers for trace IDs or tenant metadata via the optional
headersparameter. - Back up archive tables if you rely on replay semantics.
Next Steps
- Browse the full SQL surface area and release notes on the official PGMQ docs.
- Explore the pgmq GitHub repo for issues, changelog, and community examples.