Apply PostgreSQL default grants to the role that actually creates objects

Test default grants through the real PostgreSQL migration identity before approving deployment access.

Source facts

PostgreSQL 17 ALTER DEFAULT PRIVILEGES changes permissions for future objects, not objects that already exist. At creation time, the defaults of the current role apply; defaults are not inherited simply because that role belongs to another role. Defaults can be global within a database or scoped to specified schemas. Consequently, changing a convenient administrator’s defaults may not change the permissions on tables subsequently created by a different application migration role.

Source: PostgreSQL 17 — ALTER DEFAULT PRIVILEGES.

Applicability

This applies to PostgreSQL 17 schema deployment and privilege administration. It addresses future-object grant behavior and does not replace reviewing existing object permissions or application access requirements.

DSE recommendation

DSE recommends identifying the effective object-creating role used by each migration path before adjusting default grants. Keep a separate inventory of current objects that need a reviewed permission change. Have the application owner define the minimum intended access and distinguish tables, sequences, and other object types where relevant. Test the real deployment identity rather than an administrator’s interactive session. Store the approved grant policy with deployment documentation so later tooling changes do not silently change ownership assumptions.

Verification

In a test schema, create representative objects using the actual migration role and inspect their resulting privileges. Compare an object created before the change with one created afterward. Confirm required application actions succeed and unintended access fails without granting broader rights just to make the test pass.

Official reference

PostgreSQL 17 — ALTER DEFAULT PRIVILEGES. Reviewed October 15, 2026.