PGMQ, a lightweight message queue that lives inside PostgreSQL: queues, visibility timeouts and archiving in plain SQL, with no separate broker to run.
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.
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.