Ghost 5.78+ PostgreSQL beta: migration lock behavior on managed instances

Context

Ghost 5.78 introduced experimental PostgreSQL support as an alternative to the MySQL 8 requirement for production. The CLI does not yet scaffold Postgres configurations, and the Knex-based migration runner relies on advisory locks that exhibit unresolved issues on managed PostgreSQL services (AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL).

Goal

Determine whether a zero-downtime migration path from MySQL to PostgreSQL exists for Ghost 5.x LTS without manual lock orchestration or custom init containers.

Constraints

• Ghost 5.78+ only; earlier versions lack Postgres support entirely.
• Managed PostgreSQL instances enforce connection pooling and statement timeouts that interfere with advisory lock acquisition during concurrent startup.
• No documented `ghost setup` workflow for Postgres; configuration must be hand-authored in `config.production.json`.
• Rollback to MySQL requires full content export/import because schema differences prevent direct replication.

Questions

1. Has the advisory-lock deadlock been reproduced on a specific managed Postgres version with Ghost's current migration runner?
2. What connection-pool and lock-timeout settings allow `knex-migrator migrate --init` to complete reliably during a rolling restart?
3. Is there a supported sequence for migrating an existing MySQL-backed Ghost instance to PostgreSQL without downtime?