告诉 HN：Mattermost "升级" 到 v11 强制执行 1 万条 UI 消息限制
2 分•作者: nemosaltat•6 个月前
自从 2019 年以来，我就开始自托管 Mattermost（最初是为了摆脱 Slack 对家庭聊天的存储限制；后勤、照片、随机历史记录）。把他们都转移到 Slack 上是一个巨大的障碍，然后又把他们转移到 Mattermost。
今天早上，我按照 Mattermost 明确的弃用通知[0]和切换到标准二进制/Docker/k8s/etc 部署的建议，将我们长期运行的 Omnibus 安装从 v10.9.1 升级到 v11。
升级过程很顺利：
Postgres 迁移顺利
数据仍然存在于数据库中
服务在几分钟内恢复
重启后，UI 显示：
“已达到 10,000 条消息的限制。2023 年 5 月 16 日之前发送的消息已隐藏。”
澄清：没有删除任何内容。所有行仍然在 PostgreSQL 中。该限制仅适用于 UI/视图层，在“升级”后追溯应用。
事先检查过：
- Omnibus 弃用公告 [0]
- v11 升级指南 [4]
- 管理员控制台提示/链接
没有提到就地升级会激活对现有数据的硬性可见性限制。第一个迹象是重启后的运行实例。
目前（截至 2026-01-12_1337）：
- https://mattermost.com/pl/mattermost-entry-limits（应用内链接到限制）[1] 404 错误（页面未找到）
- https://mattermost.com/pricing/（也是一个应用内链接）[2] 只有“联系销售”，没有列出限制（或价格）。
- https://docs.mattermost.com/administration-guide/manage/product-limits.html [3]，使用 Kagi 找到这个，没有提到消息限制
我很乐意为受支持的软件付费。摩擦在于对自托管 + 自管理的数据库的意外强制执行。升级路径悄悄地将历史记录变成了许可功能，而升级文档中没有事先警告。
目前：
我们保留了 v11 实例（安全，当前消息正常流动）。系统控制台和仪表板无法正确加载，可能是由于消息限制，也可能是由于其他问题。
我正在考虑某种 rsync + 当前可见历史记录的静态 HTML 存档 + 用于离线搜索的数据库转储。我担心未来的策略变化可能会进一步限制访问，并且希望得到建议。
发布主要是为了警告其他即将升级的长期 Omnibus 用户（小团体、家庭、业余服务器），他们可能没有预料到视图限制会追溯生效。
如果您的安装早于限制引入，并且有超过 10k 条消息，请先在暂存环境中测试升级——或者假设文档在强制执行时间方面不完整。不要指望在论坛 [5] 中获得帮助，今天的最后一篇文章（在我今天的文章之前）是 2025 年 10 月发布的，版主将帖子指向了 Gitlab Omnibus 线程，该线程没有提供关于消息限制的详细信息，也没有回答其他问题。
想知道其他人是否在 v11“升级”中遇到了意外情况，以及是否有人有任何建议。
[0] https://github.com/mattermost/mattermost-omnibus
[1] https://mattermost.com/pl/mattermost-entry-limits
[2] https://mattermost.com/pricing/
[3] https://docs.mattermost.com/administration-guide/manage/product-limits.html
[4] https://docs.mattermost.com/deployment-guide/server/deploy-linux.html
[5] https://forum.mattermost.com/t/clarification-needed-for-the-upgrade-to-v11/25344
查看原文
I've self-hosted Mattermost since 2019 (originally to escape Slack’s retention limits for family chat; logistics, photos, random history). It was a huge hurdle getting them all on Slack, and then moving them again to Mattermost.<p>This morning, I upgraded our long-running Omnibus install from v10.9.1 → v11, following Mattermost's explicit deprecation notice[0] and recommendation to switch to standard Binary/Docker/k8s/etc deployment.<p>Upgrade went cleanly:<p>Postgres migration fine
Data still present in DB
Service came back up in minutes<p>Post-restart the UI shows:
“10,000-message limit reached. Messages sent before May 16, 2023 are hidden.”
Clarification: no DELETE FROM anywhere. All rows still in PostgreSQL. The limit is UI/view-layer only, retroactively applied after "upgrade".<p>Checked beforehand:<p>- Omnibus deprecation announcement [0]
- v11 upgrade guide [4]
- Admin console nags/links<p>None mentioned that an in-place upgrade would activate hard visibility caps on pre-existing data. First indication was the running instance after restart.<p>Currently (as of 2026-01-12_1337):<p>- https://mattermost.com/pl/mattermost-entry-limits (In-App Link to Limits) [1] 404s (Page not found)
- https://mattermost.com/pricing/ (also an in-app link) [2] only has “Contact Sales”, no enumerated limits (or prices).
- https://docs.mattermost.com/administration-guide/manage/product-limits.html [3], used Kagi to find this, no mention of message limits<p>I'm happy to pay for supported software. The friction is the surprise enforcement on self-hosted + self-managed DB. Upgrade path quietly turned history into a licensed feature without forewarning in the upgrade docs.<p>For now:<p>We're leaving the v11 instance up (secure, current messages flow normally). The system console and dashboard aren't loading correctly, possibly due to the message limits, possibly due to other issues.<p>I'm thinking some sort of rsync + static HTML archive of current visible history + DB dump for offline search. I'm afraid future policy changes could further gate access, and would love recommendations.<p>Posting mostly as warning to other long-running Omnibus users (small groups, families, hobby servers) who are about to upgrade and may not expect the view limit to kick in retroactively.<p>If your install predates the limit introduction and has >10k messages, test upgrade in staging first—or assume the docs are incomplete on enforcement timing. Don't expect to get help in the forum [5], the last post (before mine today) is from October 2025 and the moderator directed to the Gitlab Omnibus thread which doesn't provide details on message limits or answer the other questions.<p>Curious if others hit surprises on the v11 "upgrade", and if anyone has any suggestions.<p>[0] https://github.com/mattermost/mattermost-omnibus
[1] https://mattermost.com/pl/mattermost-entry-limits
[2] https://mattermost.com/pricing/
[3] https://docs.mattermost.com/administration-guide/manage/product-limits.html
[4] https://docs.mattermost.com/deployment-guide/server/deploy-linux.html
[5] https://forum.mattermost.com/t/clarification-needed-for-the-upgrade-to-v11/25344