Postgres Event Triggers
M
Mikael Siidorow
Postgres Event Triggers are required for smooth schema migrations with Sync engine services like Zero Sync. Without Event Triggers, database schema changes trigger a full re-sync which is unsuitable for production applications with >10 GB of data.
This means we need to reconsider where we can host our Postgres instance
Update: Supabase solved this without exposing real superuser, via an open source extension called supautils. See comment below for details.
Log In
M
Mikael Siidorow
Here's a concrete path forward.
Supabase open sourced an extension called
supautils
that solves exactly this problem. It registers a ProcessUtility_hook
that temporarily elevates a normal role to superuser only for the CREATE EVENT TRIGGER
syntax gate, and an fmgr_hook
ensures the resulting trigger function runs with the creating user's privileges, not elevated ones. So the elevation is scoped just to the DDL parse check, nothing else.It's been shipping in every Supabase project for a while now, so it's well tested. Installing it on Render would unblock app roles from creating event triggers without Render ever handing out a real superuser.
Concrete impact for me: Zero Sync uses event triggers for incremental schema replication. Without them, any schema change triggers a full client and server state reset, which isn't viable for production databases over 10GB. Right now that forces a move off Render for the Postgres instance, even though everything else (compute, disk, backups, HA) works great.