chore(deps): update postgresql docker tag to v18

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	OpenSSF
postgresql (source)	helm_release	major	16.7.26 → 18.2.0

---

Release Notes

bitnami/charts (postgresql)

v16.7.27

• [bitnami/postgresql] ⚡ ⬆️ Update dependency references (#​36195) (36f8598), closes #​36195

---

Configuration

📅 Schedule: Branch creation - At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday ( * 0-4,22-23 * * 1-5 ), Only on Sunday and Saturday ( * * * * 0,6 ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[seer-by-sentry]

Potential bug: The PostgreSQL Helm chart is undergoing a major version upgrade from 16.x to 18.x without an accompanying data migration strategy, risking database startup failure on existing deployments.

• Description: The PostgreSQL Helm chart version is being upgraded from 16.7.26 to 18.0.7, which is a major version jump. While persistence is not explicitly configured, the Bitnami chart enables it by default. The change lacks any data migration strategy, such as pg_dump/pg_restore or pg_upgrade procedures. If this infrastructure is applied to an environment with existing data in a persistent volume, the new PostgreSQL 18.x instance will fail to start due to data format incompatibility with the old 16.x data, causing the database to crash loop and leading to a service outage.

• Suggested fix: Implement a data migration strategy for the major version upgrade. This typically involves using pre-upgrade and post-upgrade hooks to perform a backup (e.g., pg_dump) before the chart is upgraded and a restore (pg_restore) after the new version is deployed. The upgrade should be a carefully managed process, not an automated dependency update without migration logic.
  _{severity: 0.95, confidence: 0.98}

_{Did we get this right? 👍 / 👎 to inform future reviews.}