Audit Logging

DbVisualizer includes client-side audit logging that tracks and records executed SQL statements, database metadata calls, and connection state changes. The generated log files are written in a structured format, making it easy to collect and aggregate them into a central repository.

This feature supports key organizational needs:

• Compliance auditing: Helps meet internal security policies and external regulatory requirements.
• Post-incident investigation: Provides a historical record of actions during security or operational reviews.
• Activity traceability: Identifies exactly which commands were executed against a given database target from the client side.

As it provides a full trace of the statements executed during the user's interaction with the database, the audit log can also be utilized for debugging purposes.

Enabling audit logging

Audit logging can be activated in the Audit Log section in Tools → Tool Properties. To record metadata queries and connection state changes, enable the corresponding options. Metadata queries include database tables retrieval and similar lookups. Connection state changes include operations like commit, rollback, setting current catalog and schema, etc.

Log file location

By default, audit logs files are written to the following directory:

.dbvis/logs/audit/dbvis-audit-YYYYMMDD-<u>-<g>.log

The filename components are resolved as follows:

• YYYYMMDD: The UTC date the file was opened.
• <u>: A per-process slot resolver. If multiple DbVisualizer instances run concurrently on the same machine, each instance writes to a unique slot to prevent file conflicts.
• <g>: A generation index. When a log file reaches its size limit, it rotates to the next generation number.

Audit log files are rotated on date rollover and after reaching a certain size (default is 10 MB). Old audit log files are automatically removed after a set retention period (default is 5 days).

Log entry format

Each line in the log file is a self-contained, single-line JSON object:

{"ts":"2026-04-29T08:11:50.123Z","type":"SQL","sessionId":"wVjPq3Nf4kXnBsRa7yQ8c","cmd":"SELECT id, name FROM users WHERE active = 1","connection":{"id":"abc123","url":"jdbc:mysql://localhost:3306/","ssh":"dbvisuser@128.199.49.46:22"},"database":"sys","schema":"public"}

Schema definition:

Sensitive data masking

To protect credentials, two layers of automatic masking are applied to the logs:

• Database URLs: Parameter values for sensitive keys are automatically masked (e.g. token or password).
• SQL statements: DbVisualizer uses database-specific parsing to recognize and redact password literals within common SQL commands (e.g. ALTER USER ... IDENTIFIED BY '***').

Enterprise configuration

In enterprise deployments, administrators can enforce global audit policies. The following properties are supported:

Example

To force audit logging on, disable high-volume metadata logging, and set a 30-day retention policy in a custom log directory, use the following configuration:

dbvis.auditLog.enabled=true
dbvis.auditLog.logMetadata=false
dbvis.auditLog.logConnectionChanges=true
dbvis.-auditLog.retentionDays=30
dbvis.-auditLog.directory=/var/log/dbvisualizer