Database Audit LoggingEvery action logged. Every change attributable.
Database audit logging is two systems, not one. Cloud providers cover the infrastructure layer. The workflow layer — schema changes, queries, approvals, exports — is yours to build.
Database audit logging architecture
Two layers. One trail.
Infrastructure layer
Provisioning, configuration, backups, network. Captured by CloudTrail, Cloud Audit Logs, Azure Monitor. Records are well-formatted, centrally retained, and tied to a cloud principal. Handled by the provider.
Workflow layer
Schema changes, queries, approvals, exports. Engine-native tools — pgaudit, MySQL audit plugins, SQL Server Audit, Oracle Unified Auditing — cover part of this. Three gaps remain regardless: identity, context, coverage.
Database audit logging guide
Read in order.
- 01
Start with the framework
Two layers: infrastructure (provider) and workflow (yours). What each captures and why compliance demands both.
- 02
See it in Bytebase
Workflow layer captured. SSO identity, full SQL, masking decisions. Three export paths.
- 03
Read what auditors want
Four mandatory fields. Six categories of admin activity. Lessons from our own SOC 2 audit.
Workflow-layer audit logging in Bytebase
Logged at the gateway. Available to the auditor.
Bytebase sits in front of the database. Every routed SQL is logged before execution: SSO identity, full SQL statement, target database, masking decisions, execution result. Direct connections that bypass Bytebase need engine-native auditing as a backstop.
One audit log. Every action.
Database audit logging questions
Common questions.
- What is database audit logging?
- Database audit logging is the recorded trail of database activity — who did what, when, and from where. It splits into two layers: the infrastructure layer (provisioning, configuration, backups, managed by the cloud provider) and the workflow layer (schema changes, queries, approvals, exports inside the database).
- Do I need both infrastructure and workflow audit logs for compliance?
- Yes. SOC 2, HIPAA, PCI DSS, ISO 27001, and GDPR all require an audit trail covering both layers. Infrastructure logs from CloudTrail, Cloud Audit Logs, or Azure Monitor cover provider-managed actions. The workflow layer needs separate auditing through engine-native tools (pgaudit, MySQL audit plugins, SQL Server Audit, Oracle Unified Auditing) or a workflow gateway like Bytebase.
- Which compliance frameworks require database audit logging?
- SOC 2 (Trust Services Criteria CC6.1, CC6.3, CC7.2), HIPAA (§ 164.312(b)), PCI DSS (Requirement 10), ISO 27001 (Annex A 8.15), and GDPR (Article 30). Each emphasizes different fields and retention rules — PCI DSS requires one year online, HIPAA emphasizes PHI access, SOC 2 emphasizes administrator activity.
Every post in the series.
- 01
Database Audit Logging: Two Layers, One Trail
The hub. Infrastructure-vs-workflow split, what each layer captures, what compliance requires.
- 02
How Bytebase Handles Audit Logging
The three gaps Bytebase closes, the record format, masking metadata, export paths.
- 03
Postgres Audit Logging Guide
Native logging, triggers, logical replication, pgaudit, Bytebase. Comparison table.
- 04
SOC 2 Audit Log Requirements: Lessons From Our Own Audit
What auditors actually want. Four-field framework. Six categories of admin activity.