Database audit trails are essential for compliance frameworks like PCI DSS, HIPAA, SOC 2, and GDPR. They answer the critical question: who accessed what data, when, and how? Without audit logging, you cannot detect unauthorized data access, prove compliance during audits, or investigate security incidents after the fact.
This guide compares three leading self-hosted database audit solutions: pgAudit for PostgreSQL, the MySQL Audit Plugin (formerly McAfee), and Auditbeat for infrastructure-wide audit collection. We’ll examine deployment, audit policies, performance impact, and compliance coverage.
Comparison Overview
| Feature | pgAudit | MySQL Audit Plugin | Auditbeat |
|---|---|---|---|
| Database | PostgreSQL | MySQL / MariaDB | All (via modules) |
| License | PostgreSQL License | GPL v2 | Elastic License 2.0 |
| Audit Granularity | Session, Object, DDL, DML | All queries, connections | File, process, network, socket |
| Output Format | PostgreSQL log | JSON, syslog | JSON, Elasticsearch |
| Performance Impact | Low (~2-5%) | Low (~1-3%) | Very low |
| Compliance | PCI DSS, SOC 2, HIPAA | PCI DSS, SOC 2 | PCI DSS, HIPAA, SOC 2 |
| Installation | PostgreSQL extension | Plugin installation | Binary package |
| GitHub Stars | 1,640+ | 1,550+ | 12,600+ |
pgAudit for PostgreSQL
pgAudit is the de facto PostgreSQL audit extension, maintained by the PostgreSQL community and included in many managed PostgreSQL distributions. It provides session-level and object-level audit logging with fine-grained control over which events are captured.
Key Features
- Session Auditing: Logs all queries executed within a database session
- Object Auditing: Tracks access to specific tables, columns, or functions
- DDL Logging: Captures schema changes including CREATE, ALTER, DROP, and GRANT statements
- Role Filtering: Exclude trusted roles from audit trails to reduce noise
- Log Tagging: Each audit entry includes a structured
AUDITprefix for easy parsing
Installation and Configuration
| |
For object-level auditing on specific tables:
| |
Docker Compose Deployment
| |
The init.sql file installs the extension:
| |
When to Choose pgAudit
- You run PostgreSQL and need compliance-grade audit logging
- You require object-level auditing for sensitive tables
- You want minimal performance overhead with native PostgreSQL integration
- Your compliance framework mandates DDL and DML audit trails
MySQL Audit Plugin
The MySQL Audit Plugin (originally developed by McAfee, now maintained by the MySQL community) provides comprehensive audit logging for MySQL and MariaDB servers.
Key Features
- Full Query Logging: Captures every SQL statement with user, host, and timestamp
- Connection Tracking: Logs successful and failed login attempts
- JSON Output: Structured JSON format for easy parsing and SIEM integration
- Table Filtering: Audit specific tables or exclude system databases
- Syslog Integration: Forward audit events to syslog for centralized collection
Installation
| |
Docker Compose Deployment
| |
When to Choose MySQL Audit Plugin
- You run MySQL or MariaDB and need comprehensive query-level auditing
- JSON-formatted audit logs are required for SIEM integration
- You need to track both successful and failed authentication attempts
- Your compliance mandate covers database access logging
Auditbeat for Infrastructure-Wide Audit Collection
Auditbeat is part of the Elastic Beats family and collects audit data at the operating system level — file integrity monitoring, process execution tracking, network connection logging, and user login events. While not database-specific, it provides a broader security posture view that complements database-level audit tools.
Key Features
- File Integrity Monitoring: Detects unauthorized changes to configuration files and binaries
- Process Execution Logging: Tracks all process launches with command-line arguments
- Network Connection Tracking: Logs inbound and outbound connections
- User Login Events: Captures SSH logins, sudo usage, and session events
- Elasticsearch Integration: Ships directly to Elasticsearch for centralized analysis
Docker Compose Deployment
| |
auditbeat.yml configuration:
| |
When to Choose Auditbeat
- You need host-level audit coverage across your entire infrastructure
- File integrity monitoring is a compliance requirement
- You already use the Elastic Stack for log aggregation
- You want to correlate database events with OS-level security events
Why Self-Host Your Database Audit Tools?
Database audit logs contain sensitive information about who accessed what data and when. Sending these logs to a third-party SaaS platform introduces privacy and compliance risks. Self-hosted audit tools keep all audit trails within your infrastructure boundary, satisfying data residency requirements under GDPR, HIPAA, and financial regulations.
Self-hosted audit solutions also give you complete control over log retention policies. Instead of being limited by a vendor’s retention window, you define how long audit records are kept — critical for compliance frameworks that mandate multi-year retention. The cost savings are significant too: audit log volumes can be massive, and per-gigabyte SaaS pricing becomes prohibitive at scale.
For organizations managing multiple database engines, combining pgAudit (PostgreSQL) with the MySQL Audit Plugin (MySQL) and Auditbeat (infrastructure) creates a comprehensive audit posture that covers every layer of your data stack.
For related reading, see our log integrity and tamper-evident audit logging guide and our Kubernetes security auditing tools comparison. If you need broader server security auditing, our Lynis vs OpenSCAP vs Goss comparison covers host-level compliance scanning.
Choosing the Right Database Audit Tool
For PostgreSQL environments, pgAudit is the clear choice — it is native, well-maintained, and provides the granular object-level auditing that compliance auditors expect. For MySQL deployments, the MySQL Audit Plugin delivers comparable coverage with JSON-formatted output ready for SIEM ingestion.
If your compliance requirements extend beyond the database layer to include file integrity, process execution, and network connection tracking, Auditbeat complements database-specific tools by providing the infrastructure-level context that security teams need for incident investigation.
FAQ
What is the difference between pgAudit session and object auditing?
Session auditing logs all queries executed by a database session, regardless of which tables are accessed. Object auditing is more targeted — it only logs access to specific tables, columns, or functions that you explicitly configure. Use session auditing for broad compliance coverage and object auditing for focused monitoring of sensitive data.
Does pgAudit impact PostgreSQL performance?
Yes, but the impact is minimal. pgAudit adds approximately 2-5% overhead on write-heavy workloads and less than 1% on read-heavy workloads. The actual impact depends on your audit policy — logging every SELECT on every table will have higher overhead than logging only DDL statements.
Can the MySQL Audit Plugin filter out specific users?
Yes. The audit_whitelist_users configuration parameter lets you exclude trusted accounts (like monitoring or backup users) from audit logging. This reduces log volume and focuses audit records on actual application and administrative activity.
Does Auditbeat replace database-specific audit tools?
No. Auditbeat provides infrastructure-level audit coverage (file changes, process execution, network connections) but does not capture SQL query content or database-level access patterns. Use Auditbeat alongside pgAudit or the MySQL Audit Plugin for comprehensive coverage.
How do I forward audit logs to a SIEM?
pgAudit writes to PostgreSQL’s standard log output, which can be shipped via Fluent Bit, Filebeat, or rsyslog. The MySQL Audit Plugin supports direct JSON file output and syslog forwarding. Auditbeat ships natively to Elasticsearch and Logstash. All three integrate with major SIEM platforms.
What compliance frameworks require database audit logging?
PCI DSS (Requirement 10), HIPAA (Security Rule §164.312(b)), SOC 2 (CC6.1, CC7.2), and GDPR (Article 30) all require audit trails for data access. Financial regulations like SOX and Basel III also mandate comprehensive audit logging for database systems handling regulated data.