Rework cloud upgrades page for clarity

[atovpeko]

Describe your changes

Restructures the Tiger Cloud "Maintenance and upgrades" page (src/partials/_upgrades.mdx) into two clearly separated top-level sections — TimescaleDB upgrades and PostgreSQL upgrades — based on which component is being upgraded, so readers can find what applies to them without conflating the two products.

Key changes:

• Top-level split: TimescaleDB upgrades vs PostgreSQL upgrades, with parallel sub-bullet structure in the policy overview at the top.
• TimescaleDB section:
  • Non-critical upgrades covers minor versions and patch releases (renamed from the ambiguous "Minor software upgrades").
  • Critical security patches is now its own subsection rather than buried in a bullet.
  • New Downtime and connection resets subsection consolidates scattered downtime guidance and absorbs the rewritten "Minimize downtime with replicas" content. The failover mechanics are explained more clearly.
• PostgreSQL section:
  • States up front that new minor PG versions are applied automatically during the maintenance window, and that major version upgrades are user-driven on your own schedule.
  • Automatic upgrades only happen when a PG version reaches end-of-life — this trigger is now emphasized in both the policy bullet and the subsection.
  • Renamed the confusing "self-service upgrade window" to "manual upgrade period" so it does not collide with "maintenance window".
• New Check your current versions section pointing readers to Operations > Service Upgrades in Console, with a screenshot.
• Screenshots upgraded to ThemeImage pairs (light + dark) for the existing maintenance-window image and the new Service Upgrades image.
• Removed a misleading cross-link to the Service Management page that did not belong in the upgrade context.
• Anchor links updated to match new heading structure. The only externally-referenced anchor (#define-your-maintenance-window, from _migrate_prerequisites.mdx) is preserved.

Open items to confirm with engineering:

• Does an automatic PG upgrade (for an EOL version) actually run during the configured maintenance window? Page currently states yes.
• Are new minor PG versions automatically applied during the maintenance window? Page currently states yes.

Affected pages

https://tiger-data-docs-git-atovpeko1-edu-540-rework-c-32a5c2-tigerdata.vercel.app/deploy/tiger-cloud/tiger-cloud-aws/upgrades

Related Issues

EDU-540 — Rework Cloud upgrade docs for clarity

Checklist before requesting a review

• - This is ready for review. If not, raise as a draft PR
• - I have reviewed my changes.
• - I have confirmed the content is technically accurate.
• - I have tested any code that is added or updated on the latest available version.
• - I have confirmed the content is free of typos or grammar errors.
• - I have verified all images and videos are clear and match production (or dev for unreleased features).
• - This references a feature that is public. If not, add a note and we can schedule the merge for after the feature release.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tiger-data-docs	Ready	Preview, Comment	May 26, 2026 11:53am

[atovpeko]

@miqrc can you provide additional details here, on the phased rollout?

[minkimipt]

Why do we call them standard? Also, we don't send notifications from the infra for individual DBs. We just announce the release and what is going to happen. Here's the example announcement, which is also contained in emails that are sent by our status page.

Suggested change

Non-critical upgrades — including new minor versions and patch releases — are applied automatically in the next available [maintenance window](#define-your-maintenance-window). The upgrade is first applied to your standard {C.SERVICE_SHORT}s tagged `#dev`, and three weeks later to those tagged `#prod`. [Subscribe](https://status.tigerdata.com/) to get an email notification before your `#prod` {C.SERVICE_SHORT}s are upgraded. If there are no pending upgrades during a maintenance window, no changes are performed.

Non-critical upgrades — including new minor versions and patch releases — are applied automatically in the next available [maintenance window](#define-your-maintenance-window). The upgrade is first applied to your {C.SERVICE_SHORT}s tagged `#dev`, and three weeks later to those tagged `#prod`. [Subscribe](https://status.tigerdata.com/) to get an email notification before your `#dev` {C.SERVICE_SHORT}s are upgraded. No separate notification is sent when your prod service is updated. If there are no pending upgrades during a maintenance window, no changes are performed.

[miqrc]

@atovpeko This is the text I would use here (please apply the templating if needed, i.e. SERVICE_SHORT, etc.)

Non-critical upgrades

Non-critical upgrades — new minor versions and patch releases — are applied automatically in the next available maintenance window. Subscribe to get an email notification before your {C.SERVICE_SHORT}s are upgraded. If there are no pending upgrades during a maintenance window, no changes are performed.

The schedule depends on the upgrade type and your service's environment tag:

• New minor versions on #dev services: applied in the next maintenance window after the release.
• New minor versions on #prod services: applied in the next maintenance window three weeks after the release. This gives you three weeks to validate the release on your #dev services first.
• Patch releases: applied in the next maintenance window on both #dev and #prod services, with no waiting period.

Occasionally, a new minor version is released before the previous one has completed its three-week window — for example, when it contains an important fix. In that case, the newer minor version takes priority: your #prod services skip the previous minor and target the new one instead, and the three-week window restarts from the new release. Your #dev services move to the new minor in their next maintenance window, as usual.