Audit Logs

Every DDL/SQL operation is logged (user, role, statement, target, success/error). The Audit Logs page (requires audit.view, Admin by default) filters by operation, user, date, and success. Auth events (logins, key exchanges, revocations) are logged separately by the Auth API.

DML audit retention

Row changes are recorded separately from operations. When a table carries the DML audit triggers, every insert, update and delete adds a row holding a full JSON image of the affected row — before and after — so that trail grows with how much is written, not with how much is done.

What is kept. The daily retention sweep removes row-change entries older than the window and nothing else. The default window is 90 days. You can set anything from 7 to 3650 days, and 0 turns the purge off entirely — rows are then kept indefinitely, which is worth choosing deliberately rather than by accident.

How to change it. Settings → DML audit retention, or dlake audit retention set <days>. Viewing the window needs audit.view; changing it needs the same permission as the other tenant settings. A change applies on the next daily sweep — nothing is deleted at the moment you save it, and a large backlog is removed over several nights rather than in one long transaction.

What is never audited. Tables the platform itself owns (users, API keys, settings, the sync pipeline’s own tables) and tables fed by a connector are never given audit triggers at all. A sync run rewrites thousands of rows at a time and the connector’s own run history already records what changed and when, so a second, much larger copy of it would be cost without an answer. Tables that already record their own history — change logging, or audit stamping — are left alone for the same reason. Retention therefore governs your own tables’ row history, and the setting has no effect on what a sync writes.

Purge now. You do not have to wait for the nightly sweep. Settings → DML audit retention → Report what would be purged counts the rows older than your window and the megabytes of row images they hold, and deletes nothing; after a report, Purge now (it asks once) removes them straight away, using the same batches and the same time limit as the nightly sweep, and says how many rows went, whether the time limit stopped it early, and how long it took. From the CLI it is dlake audit purge (report) and dlake audit purge --run (purge). A purge is refused while the purge is off (0), because that setting means “keep this history”; a report still works and counts against the platform default window, and says so. Both need the same permission as changing the window, and every run is recorded in the audit trail with the name of whoever asked for it. Removing rows frees space inside the database file — see Database storage below for how that space is given back.