postkit db start silently drops RLS policies, GRANTs, and ALTER DEFAULT PRIVILEGES referencing custom roles during database clone #48

Summary

postkit db start silently omits Row-Level Security (RLS) policies, GRANT statements, and ALTER DEFAULT PRIVILEGES that reference custom database roles (e.g. admin, employee, service_role, app_user, authenticator) when cloning a remote PostgreSQL database into the local session database.

Although PostKit reports "Database cloned successfully.", the resulting local database is not structurally equivalent to the source database.

Environment

• OS: macOS (Darwin)

• PostgreSQL: 17 (postgres:17-alpine)

• pgschema: 1.9.0

• Reproduced with:

  • Automatic Docker clone (postkit db start)
  • Direct localDbUrl clone path

Expected Behavior

The cloned local database should preserve all schema objects and permissions from the source database, including:

• Row-Level Security (RLS) policies
• GRANT statements
• ALTER DEFAULT PRIVILEGES
• References to custom database roles

The cloned database should be structurally identical to the remote database.

Actual Behavior

The clone completes successfully and reports:

Database cloned successfully.

However, all permission-related objects that reference custom roles are silently omitted. As a result, the local database differs from the remote database immediately after postkit db start, with no warnings or errors indicating that these objects were skipped.

Impact

The cloned database is not structurally equivalent to the source database.

Because the RLS policies, GRANT statements, and ALTER DEFAULT PRIVILEGES are not preserved during cloning, PostKit attempts to recreate them during subsequent schema diff/apply operations. This produces unnecessary schema differences and causes permission-related objects to be recreated instead of being present immediately after the clone.