A customer calls. Says they never changed their password.
But it was changed yesterday. Now they're locked out.
You have no idea what happened. Neither does your team.
With an audit trail, you'd know in seconds: who did it, when, and how.
FOUNDATIONAL - Without audit trails, you're flying blind when something goes wrong.
An audit trail is a chronological record of every significant action in your system. User logged in. Record updated. Permission changed. File deleted. Each entry captures who did it, what they did, when they did it, and often why (the context that triggered it).
The key property: immutability. Once an event is recorded, it can't be changed or deleted. Not by users. Not by admins. Not even by the person who runs the database. This is what makes audit trails useful for compliance and investigations.
Without this, you're left guessing. "The data looks wrong but I don't know who changed it." "Someone says they didn't do that but I can't prove otherwise." "The regulator wants evidence of our data handling and I have nothing."
Get it wrong and you're defenseless in an investigation. Get it right and you can answer "what happened?" in seconds.
Audit trails solve a universal problem: when something changes, you need proof of exactly what changed, who changed it, and when. This pattern shows up everywhere trust and accountability matter.
Append-only log. Every action becomes a record. Records are immutable. The current state is just the result of all the actions that came before it.
Switch users and attempt actions. Notice: EVERY action gets logged, including denied ones.
0
Total
0
Successes
0
Denials
No entries yet.
Try an action to see it logged.
Most common approach
Every time a record changes in your main tables, a trigger or application code inserts a row into an audit table. The audit table stores: table name, record ID, action (create/update/delete), old values, new values, user ID, timestamp.
The audit trail IS the data
Instead of storing current state, you store every event that ever happened. "User created", "Email updated", "Account closed". Current state is derived by replaying events. The audit trail isn't separate, it's the source of truth.
Send events to a separate system
Push audit events to a dedicated service (Datadog, Splunk, a SIEM). The logging system is separate from your application, so even if your app is compromised, the audit logs are safe.
A customer is locked out and says they never changed their password. Without audit trails, you're stuck guessing. With this flow, you can see the exact moment it happened, what triggered it, and from where.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
Your audit_logs table has the same permissions as your regular tables. A bad actor (or a panicked engineer) just runs DELETE FROM audit_logs. Now you have no evidence of anything.
Instead: Use append-only tables, separate databases with restricted access, or external immutable storage.
You log when someone updates a record, but not when they try and fail. An attacker tries 1000 passwords. None worked. You have no record of the attack.
Instead: Log failed attempts, permission denials, and validation errors. Often more valuable than success logs.
Your log says "User 47 updated customer record 123." Great. What did they change? You don't know. Was it the address or the credit limit? You can't tell.
Instead: Store before and after values. Field name, old value, new value. The diff is often the whole point.
You've learned why immutable records matter and how to implement them. The natural next step is understanding how permissions control who can do what in the first place.