Not a duplicate. The forum's Eliminate 4000 character per message idea is marked Completed — it raised the cap to 16,383 in v5.0. This asks for the step after that: make the limit configurable (and/or raise the Postgres default), because 16,383 is now the wall for long-form agent and automation content. Completed ideas no longer collect votes, which is why this is a separate idea.

What happened. A user pasted a ~22,000-character research brief and got "Your message is too long. Character count: 22703/16383." They attached it as jj.txt instead. That moved the brief off post.message and onto the file path, where it arrived as an untyped binary blob (a separate issue on our side), the agent skipped it, asked for a re-send, and the user re-uploaded the same file. About ten minutes and one confused conversation for four pages of text.

What we checked. There is no setting: mmctl config get ServiceSettings.MaxPostSize returns invalid key, and the System Console has nothing. Reading post_store.go, the limit is max(posts.message column length / 4, 16383), computed once at startup — the 16,383 is 65535 / 4, the utf8mb4 worst case of the old MySQL varchar(65535), applied to Postgres too. The code comment says the column "may be manually enlarged to support longer posts," so the mechanism exists, but only as undocumented, per-database ALTER TABLE surgery that a future migration could silently undo.

Why it matters beyond us. Long-form content into chat is no longer an edge case: pasted logs and reports (the original GitHub ask, #28434), LLM-generated summaries, and now agent briefs. Forcing everything over 16 K through file attachments loses inline rendering, quoting, and search, and splits every integration into two code paths.

The ask. A server setting — e.g. ServiceSettings.MaxPostSize, admin-only, default 16383 for compatibility — validated at startup against the real column capacity the server already measures, so it can never exceed what the database stores. Clients already read MaxPostSize from client config, so web, desktop and mobile would follow with no client work. Alternatively, raise the Postgres default now that the column is not limited to 65,535 bytes.

Related: https://github.com/mattermost/mattermost/issues/28434 (closed with a redirect here, no change).