PostgreSQL 18 with PGMQ on Ubuntu 24.04 LTS

Azure Streaming & Messaging

PGMQ, a lightweight message queue that lives inside PostgreSQL: queues, visibility timeouts and archiving in plain SQL, with no separate broker to run.

Base
Hardened build
minimal ports, security patches applied at build time
Access
Unique credentials
generated on first boot, readable only by root
Verified
Boots working
services pass a health gate before release
Support
24/7, 365 days
by email and live chat, 24 hour response SLA

Overview

PGMQ turns PostgreSQL into a message queue. Queues are ordinary tables and the entire API is a set of SQL functions, so you create a queue, send a JSONB message, read it with a visibility timeout and archive it without adding a broker, a second cluster or another service to monitor. It gives you the semantics teams expect from a queue, delivery counting so poison messages surface, archiving so processed work stays auditable, and unlogged and partitioned queue shapes for high throughput and cheap retention.

The reason teams choose it is transactional integrity. Because the queue shares a database with the application data, enqueuing a job and writing the row that job refers to commit in one transaction, so a message is never published for work that was rolled back and never lost for work that was committed. That removes an entire class of dual write bugs that appear whenever the queue is a separate system, and it means existing backups, monitoring and replication already cover the queue.

Why the cloudimg image

cloudimg ships PostgreSQL with the PGMQ extension already built and enabled in a ready to use database, alongside pg_partman so partitioned queues work immediately rather than erroring on first use. A seeded demo queue lets you read a message the moment the instance boots. There is no default password to change: on first boot each instance generates its own database password and its own TLS certificate, written to a file only the root user can read, and remote connections are accepted only over TLS. Each image also carries a built in self test that proves the full send, read, archive lifecycle over an encrypted connection, so you can verify the appliance end to end at any time. The build toolchain is removed before capture to keep the image lean, and every instance carries 24/7 support.

Common uses

  • Background jobs and task queues that commit in the same transaction as your data
  • Event and work distribution between services without running a separate broker
  • Durable retry and dead letter handling using visibility timeouts and delivery counts