PostgreSQL + pgAudit

Azure Databases 1 variation

A PostgreSQL database that arrives already auditing, with pgAudit preloaded, a deliberate policy and a trail that cannot fill the disk.

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

Variations

This product is available in the build below. Open it for the operating system, cloud and version detail, or read its deployment guide.

ProductCloudOperating systemVersion
PostgreSQL 18 with pgAudit on Ubuntu 24.04 LTS Azure Ubuntu 24.04 18 View · Guide

Overview

This appliance is a PostgreSQL database with pgAudit, the PostgreSQL Audit Extension, already loaded into the server process and enabled in a ready to use database. pgAudit is the control named in PCI-DSS, SOC 2 and HIPAA guidance for PostgreSQL, and it is the one extension a team cannot simply switch on in a running database: it has to be loaded through the server's preload list, which means a configuration change and a restart.

What it produces is a trail that ordinary statement logging cannot: structured, classified entries naming the class of the statement, the command, the object type and the fully qualified object, in a format that parses cleanly into a SIEM. It suits regulated workloads that have to evidence who changed the schema and who was granted access, and any team that needs a defensible database audit trail without building the packaging and the log management around it themselves.

Why the cloudimg image

Preloading the extension and leaving it at its defaults is the easy half. cloudimg ships a policy that is actually operable: session auditing records every schema change and every privilege change, while read and write auditing is opt in per table through a dedicated role, so the trail never becomes a firehose on a busy database. Bound parameter values are deliberately never written, so the audit trail cannot become a second copy of the data it is auditing. The trail is also bounded: it lives in its own root only directory, rotated by the database and swept hourly against both an age cap and a hard total size cap, so a long running instance cannot fill its own disk with audit data, and both limits are one configuration file away from your own retention policy. There is no default password to change and no shared database: every instance initialises its own cluster on first boot with its own generated passwords and its own TLS certificate, written to a file only the root user can read, and the database listens on loopback until you choose to open it. The paired deployment guide walks through making an audited change, reading the entry it produced, and turning auditing on for a table of your own, and every instance carries 24/7 support.

Common uses

  • Evidencing schema and privilege changes for PCI-DSS, SOC 2 or HIPAA audits
  • Per table read and write audit trails for sensitive data, without auditing everything
  • Feeding a structured, parseable database audit stream into a SIEM