MariaDB Audit Plugin: Track Every Query for Compliance (2026)

The MariaDB Audit Plugin doesn’t just log queries; it fundamentally changes how you think about database security by making every interaction a traceable event.

Let’s see it in action. Imagine you have a users table, and you want to ensure no one is snooping around directly.

-- On your MariaDB server, enable the plugin
SET GLOBAL plugin_load_add='ha_audit.so';

-- Configure what to log. Let's log all DML and DDL for a specific user.
SET GLOBAL audit_log_policy='ALL';
SET GLOBAL audit_log_exclude_commands='CONNECT,DISCONNECT'; -- We'll log connection attempts separately if needed
SET GLOBAL audit_log_include_users='app_user'; -- Only log for 'app_user'

-- Now, let's simulate some activity as 'app_user'
-- First, a SELECT that should be logged
SELECT * FROM users WHERE id = 1;

-- Then, a DDL change that should be logged
CREATE TABLE IF NOT EXISTS audit_trail_test (id INT);

-- And a DELETE that should be logged
DELETE FROM users WHERE username = 'test_user';

Now, where do those logs go? By default, MariaDB will write them to a file named audit.log in its data directory. You can find this directory by running SHOW VARIABLES LIKE 'datadir';. The exact path will be something like /var/lib/mysql/audit.log.

# On the server, tail the log file
tail -f /var/lib/mysql/audit.log

You’d see entries for your SELECT, CREATE TABLE, and DELETE statements, including the timestamp, the user who executed them, the command type, and the actual SQL.

The core problem the Audit Plugin solves is the "who did what, when" question in a complex, multi-user database environment. Without it, tracking down unauthorized data modifications or understanding the sequence of events leading to a security incident is largely guesswork, relying on application logs or fragmented server logs. This plugin provides a single, authoritative source of truth for database activity.

Internally, the plugin hooks into MariaDB’s command execution flow. When a command is processed, the audit plugin intercepts it, checks your configured policies (audit_log_policy, audit_log_include_users, audit_log_exclude_commands, etc.), and if it matches, writes a structured log entry to the configured destination (file or syslog).

The exact levers you control are numerous:

• plugin_load_add='ha_audit.so': This is the initial step to load the plugin. You can also set plugin_dir if the .so file isn’t in the default location.
• audit_log_policy: This is your primary filter. The options are:
  • NONE: Disables auditing.
  • LOGINS: Logs only connection/disconnection events.
  • QUERIES: Logs all executed queries.
  • ALL: Logs both connection events and all queries.
• audit_log_exclude_commands: A comma-separated list of SQL commands (like CONNECT, DISCONNECT, SELECT, UPDATE, DELETE, CREATE, DROP, etc.) to exclude from logging, even if audit_log_policy would normally include them. This is useful for reducing noise from high-frequency, low-impact commands.
• audit_log_include_commands: The inverse of exclude. A comma-separated list of commands to include. If this is set, only these commands will be logged.
• audit_log_include_users: A comma-separated list of users whose activities should be logged. If set, only these users’ commands are audited.
• audit_log_exclude_users: A comma-separated list of users whose activities should not be logged.
• audit_log_format: Defines the output format. JSON is common for programmatic parsing, while RAW is more human-readable.
• audit_log_file: The path to the log file if audit_log_policy is not NONE and you’re not using syslog.
• audit_log_flush: A boolean. If ON, the log file is flushed after every write, ensuring durability but potentially impacting performance.

One aspect often overlooked is how the plugin handles sensitive data. While it logs the SQL statement itself, which might contain PII if not properly parameterized in the application, the plugin itself doesn’t mask or encrypt the log content. If you log SELECT * FROM users WHERE email = 'sensitive@example.com';, that exact string, including the email, will appear in the audit log. This means your log management strategy must account for data privacy regulations before enabling logging, potentially by filtering sensitive data at the application level or by ensuring the audit logs themselves are stored in a secure, access-controlled environment.

The next hurdle you’ll likely face is managing the sheer volume of audit logs, especially in busy systems, and integrating them into a centralized logging and SIEM solution for analysis and alerting.