We keep many large tables, such as audit logs, API keys, connection logs, and now Bridge's request logs for forensic purposes, meaning that, in the case of an incident, an admin can find all of the details necessary for an event.
However, many customers prefer to use an external data source/SIEM (e.g. Splunk, Datadog) as their source of truth and want to keep the Coder PostgreSQL database relatively small/lightweight. This has several advantages:
- Data centralization (logs are centralized across tools, not just Coder)
- Low database cost (keep PostgreSQL disk/resources low)
- Improved day-to-day database performance (queries by Coder perform better rather than going across all rows)
- Improved migration performance (when upgrading Coder, migrations do not have to go through many sources)
- PostgreSQL typically isn't technically fantastic at holding these types of event-based data indefinitely and there are better options.
In fact, our documentation actually mentions how to purge audit logs: https://coder.com/docs/admin/security/audit-logs#purging-old-audit-logs
Definition of done
We keep many large tables, such as audit logs, API keys, connection logs, and now Bridge's request logs for forensic purposes, meaning that, in the case of an incident, an admin can find all of the details necessary for an event.
However, many customers prefer to use an external data source/SIEM (e.g. Splunk, Datadog) as their source of truth and want to keep the Coder PostgreSQL database relatively small/lightweight. This has several advantages:
In fact, our documentation actually mentions how to purge audit logs: https://coder.com/docs/admin/security/audit-logs#purging-old-audit-logs
Note
For full context, check out our most recent R&D reto
Definition of done
Bridge Request LogsAI Bridge docs updates docs: add data retention and export documentation for AI Bridge #21055