[bosconi]

Dates in RC snapshots are provisional until the release ships. One commit is added per snapshot; the final snapshot sets the real dates.

⚠️ Needs the release owner before this can merge

1. This PR conflicts with main, and the conflict is substantive. While this PR sat open, #40201 ("docs: describe which SQL Server constraint Materialize records as a key") merged to main on 2026-11-05 and independently added its own ## v26.49.0 section — an ### Advisory {#v26.49-advisory} plus an ### Improvements {#v26.49-improvements} bullet. Both sides edit the same region of _index.md, so mergeable is CONFLICTING.

Two problems ride along with the conflict:

• The same PR is described twice. #40201 documents the behavior of #40131, which rc.1 already published here as a Bug Fix ("Reduced the risk of new SQL Server source tables returning incorrect results after a unique constraint or primary key is dropped upstream…"). Recommendation: keep #40201's Advisory and Improvement and drop the rc.1 bug-fix bullet — the hand-written pair is more complete, carries the upgrade-impact guidance, and links /ingest-data/sql-server/#unique-keys.
• Anchor collision. main's ## v26.49.0 carries {#v26.49-advisory} and {#v26.49-improvements}; this branch's combined section carries {#v26.49-improvements}, {#v26.49-agent-skills}, and {#v26.49-bug-fixes}. Merging both defines #v26.49-improvements twice on one page. Recommendation: rename this branch's three anchors to {#v26.49.1-improvements}, {#v26.49.1-agent-skills}, {#v26.49.1-bug-fixes} — which is what the v26.49.1 snapshot's review notes intended — and leave {#v26.49-advisory} and {#v26.49-improvements} to #40201's section. #40201's review links already point at /releases/#v26.49-advisory, and the compatibility YAML's /releases/#v26491 target is unaffected.

2. Wording drift against the merged v26.49.1 snapshot. Commit 39e6b854a landed here on 2026-11-05, before MaterializeInc/mz-skills#355 merged on 2026-11-06. Two entries read differently on the branch than in the merged snapshot — the hydration improvement is "Investigate hydration on the cluster details page" here versus "See how a cluster hydrated, and why it did not" there, and the Freshness and Disk-column bullets differ likewise. Resolving the conflict above is the natural moment to decide which wording ships.

Note on the section heading

The v26.49.1 patch train reused this branch (commit 39e6b854a) rather than opening its own, so this PR now publishes a single combined ## v26.49.1 section — this train's rc.1–rc.3 entries plus the three v26.49.1 entries, with the Cloud version in parentheses. That is the house convention for a patch that ships in its parent's rollout week; compare the published ## v26.48.2 (*Released to Materialize Cloud: 2026-10-29 (v26.48.0)*). The compatibility YAML accordingly carries one v26.49.1 row dated 2026-11-06, which is what actually shipped to Self-Managed that day.

The final commit for this train is therefore empty: its increment carries no entries (MaterializeInc/release#635 states "No PRs in v26.49.0 require review", v26.49.0-rc.3...v26.49.0 is the lone version-bump commit, and the agent-skills window is empty), and the real dates — Cloud 2026-11-05, Self-Managed 2026-11-06 — were already set by 39e6b854a. It exists so the branch's commit-subject ledger records that the snapshot was applied.

Decisions required (carried over from rc.1)

• DROP INDEX (#39098): it now rejects drops that used to succeed. Call it out as a breaking change rather than an Improvement?
• Console on large clusters (#40306): the Cloud Console deploys separately, so this may already be live. Keep it in v26.49?
• Maintained Objects page (#40105): omitted because it is behind a LaunchDarkly flag. Is it generally available?
• mz profile init OAuth (#40319): omitted because the PR lists open items. Which mz release carries it?
• Upsert v2 (#40189): still omitted because enable_upsert_v2 is false. Publish it?

Snapshot drafts (with PR links) in mz-skills

• rc.1: release_notes.md, omitted.md, MaterializeInc/mz-skills#351
• rc.2: release_notes.md, omitted.md, MaterializeInc/mz-skills#352
• rc.3: release_notes.md, omitted.md, MaterializeInc/mz-skills#353
• final: release_notes.md, omitted.md

Borderline PRs omitted: rc.1: 10 — rc.1/omitted.md#borderline, rc.2: 0, rc.3: 0, final: 0

🤖 Generated with Claude Code

[maheshwarip]

@val-materialize could I get your eyes on this one? I changed the wording from the original note because I couldn't understand it!

[val-materialize]

Happy to keep your wording. The one thing it misses: older tables still keep the extra keys, so they can return wrong results if one of those constraints is dropped upstream. Can you add a line like: “Tables created before this release keep every key they recorded. Before dropping a PRIMARY KEY or UNIQUE constraint that the capture instance does not use from one of these tables, re-create the table in Materialize.”