After upgrading from 3scale 2.13 to 2.14, Zync pods on AWS Aurora Postgres v13.x fail to start unless the DB user has superuser privileges.

• In 2.13, Zync worked without superuser access.

• In 2.14, every pod restart triggers PG::InvalidSchemaName errors when superuser is not granted.

• Granting rds_superuser resolves the issue, but removing it causes failures again.

• Permanent superuser access is not acceptable for security best practices.

Steps to Reproduce:

1. Deploy 3scale 2.14 with external Postgres v13.x.

1. Configure Zync DB user without superuser privileges.

1. Restart Zync pods → observe PG::InvalidSchemaName error.

1. Grant superuser → pods start successfully.

1. Remove superuser → error returns on next restart.

Expected Behavior: Zync should only require standard read/write privileges after initial setup.

Actual Behavior: Pods fail unless superuser privileges are permanently granted.

Impact:

• Security risk: superuser access in production.

• Operational risk: pods cannot restart cleanly.

Environment:

• AWS Aurora RDS Postgres v13.x

• 3scale API Management 2.14.0

• External DB integration

Notes:

• Behavior change confirmed between 2.13 and 2.14.

• Docs mention full permissions but don’t clarify runtime vs installation.

• Workaround: grant superuser temporarily during install/upgrades, then revoke.

Requested Action:

• Confirm if this change is intentional in 2.14.

• Clarify exact DB privilege requirements (runtime vs installation).

• Update documentation.

• If unintended, provide fix or guidance to avoid permanent superuser requirement.