# Recommend Two Options — LTS vs Latest (Task 5)

Part of the Mode B workflow (see [mode-b-discovery.md](upgrade-planning-mode-b-discovery.md) for Tasks 1–4). Also used by Mode A advisory answers.

Always present both:

- **Latest version**: highest minor within the newest supported major. More features and performance, but shorter support window before the next required upgrade.
- **LTS version**: Aurora PostgreSQL 16.8 / 17.7 (designated LTS minors). Extended support window (~3 years), critical fixes only, fewer required upgrade cycles.

## Designated LTS versions

This table is authoritative for "what's the LTS version right now" questions when live AWS is unreachable. AWS designates an LTS release **per supported major version simultaneously** — there is no single engine-wide LTS value. The correct LTS minor is whatever `describe-db-engine-versions` / the AWS LTS page lists for the major the customer targets. You MUST answer "what's the current LTS version" per the major the customer is on (the LTS minor depends on the major), not as a single engine-wide answer, and you MUST NOT list every minor version as if each were LTS. These move over time — verify via `describe-db-engine-versions`.

| Engine | Designated LTS (one per major) | Non-LTS (also supported) | Aurora's LTS commitment |
|---|---|---|---|
| Aurora PostgreSQL | **17.7 and 16.8** (designated LTS minors); full per-major LTS list: 17.7, 16.8, 15.10, 14.6, 13.9, 12.9, 11.9 | latest non-LTS 17.y minors newer than 17.7 | Minimum ~3 years of Aurora-extended support on each LTS minor, with only critical / security patches. |

**Important clarifications (address these explicitly when the user asks about LTS):**

1. **LTS is not a separate MAJOR version**. It's a specific MINOR release within a supported major that Aurora designates as "Long-Term Support." For Aurora PostgreSQL, 16.8 is the LTS minor within the 16.x major; other 16.y minors are released on the regular cadence but 16.8 (the designated LTS) receives only critical fixes and is supported for ~3 years. AWS designates one LTS minor per supported major simultaneously (e.g. 17.7 is the designated LTS minor within 17.x).
2. **Older versions are NOT LTS just because they're older — but several older majors DO have a designated LTS minor.** Do not tell the user "PostgreSQL 11.9 is LTS" as if any old version qualifies. The designated per-major LTS minors are 17.7, 16.8, 15.10, 14.6, 13.9, 12.9, 11.9 — so 12.9 / 13.9 / 14.6 / 15.10 ARE the designated LTS minors for their respective majors (the real lifecycle caveat for the older ones is end-of-standard-support, not LTS status).
3. **LTS is opt-in via parameter choice at upgrade time** — you're not automatically on LTS. When upgrading, you choose an LTS minor (e.g. 16.8, or 17.7) vs. a latest non-LTS minor.
4. **Why pick LTS over latest:**
   - **Longer stability window**: ~3 years of support vs. ~1 year for a non-LTS minor.
   - **Patch cadence is predictable**: only critical fixes land; no quarterly feature-or-behaviour changes that force re-testing.
   - **Fewer required upgrade cycles**: reduce operational overhead for teams that can't test upgrades quarterly.
   - **Regulatory alignment**: auditors often expect 1–3 year rolling platform refresh cycles; LTS fits cleanly.
5. **Why pick latest over LTS:**
   - **Access to new features**: vector data types, logical replication improvements, newer SQL syntax, better parallelism.
   - **Performance improvements**: newer versions are typically 5–15% faster on analytic workloads.
   - **Security modernization**: deprecated crypto removed sooner.
6. **Trade-offs you MUST surface when the user asks:**
   - On LTS you must **disable automatic minor version upgrades**, or Aurora will move you off the LTS minor onto the latest non-LTS during the next maintenance window. Set `AutoMinorVersionUpgrade: false` on the cluster and its instances.
   - Staying on LTS means you will not get non-critical bug fixes or new features until you deliberately upgrade to a later LTS or the current latest.
   - LTS versions also get upgraded eventually — when Aurora designates a new LTS minor for a newer major (the current LTS minors change over time; verify via `describe-db-engine-versions`), you'll need a major-version upgrade cycle then too.

**Constraints:**

- You MUST present both options with trade-offs, not just one
- You MUST NOT recommend LTS unconditionally — frame it as a choice based on risk tolerance and upgrade-cadence capacity
- You MUST NOT list every minor version as if it were LTS. AWS designates one LTS minor per supported major, so the answer depends on the major the customer targets.
- When the user asks "what's the LTS version right now", you MUST cite the table above and the specific LTS minor for the relevant major (e.g. "the current Aurora PostgreSQL LTS minor for the 16.x major is 16.8, and for 17.x it's 17.7"), not a long list of minor versions.