Cloud version

[MichaelDBA]

Since you are simply using an extension that uses SQL, you can make this available for contexts like the cloud that do not have access to the underlying operating system. Just simply import the file supa_audit--0.2.3.sql but first add the creation of the uuid ossp extension to the top of that file: CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

This could simply be added to the documentation instead of adding it as a feature request.

[olirice]

We chose to leave that option out of the README because it doesn't leave a good upgrade path unless the user is willing to periodically check back at the repo and run any new upgrade scripts.

We're still seeing occasional new issues that require updates to the extension. Once that tails off it might make sense to add a SQL only install option in the README for people on hosted platforms.

Would you be interested in opening a PR to update the README with the instructions + the upgrade caveat?

[MichaelDBA]

Sure, PR is ready

[olirice]

Note to self:

Once the extension has been stable w/ no major reported bugs for a few months, document installing as a SQL script.

Ref: #31 (comment)

TODO:

• Add caveats that it is the users responsibility to check back for upgrade scripts

[MichaelDBA]

Good point about that caveat.

[zedeus]

@olirice I'm using this in production with Supabase. I installed it by removing the two pg_catalog lines and running it as a normal migration. Are there any plans to continue work on this extension, and make it available for easy installation on Supabase?

[olirice]

we don't plan to continue development on supa_audit. It was a companion repo for a blog post we wrote a few years ago https://supabase.com/blog/postgres-audit that got more attention than expected

our recommendation is to use pgAudit, which is pre-installed on all supbase instances

[rigor789]

We've looked into pgAudit, however the logs don't quite contain useful information when triggered by the js client via postgREST. Wondering whether or not using supa_audit would be fine in most cases given existing features work well enough?

[olirice]

You're welcome to make that decision for yourself if its for internal use
Be aware that if it is for external compliance (e.g. SOC2) your audit system can't be reliant on the tool that its auditing. For example, if postgres crashed catastrophically, you would lose your audit data. That disqualifies supa_audit from that usecase

[rigor789]

Gotcha, thanks for the clarification! We'd be using this for internal alerting/auditing on a specific table - application level, nothing external, but seems like that should be fine to do. (Alternative would be to bake this into the application itself, but we kind of like the idea of it being independent).