EvgeniyMich

Частообновляющийся json/jsonb может существенно отжирать дисковое пространсто, необходимо агрессивно вакуумировать. В облаке вероятно это может быть незаметно, но это создает неоптимальную нагрузку на PG.
Возможно стоит пересмотреть архитектуру сбора данных. В зависимости от характера нагрузки, но к примеру если у вас событие длится конечное время, можно писать частообновляющиеся данные в память(например в Redis). А когда событие окончится - дампить в базу. Таким образом извлечение данных за прошедшие события будет оптимальным, и запись в postgresql будет оптимальная.

Блоб по которому вы не ищете нет смысла нормализовать. Если сравнения, выборки и и сортировки по нему не производятся, а данные участвуют только в логических операциях вне БД, нормализация и перепроектировка не требуется.

Тут сложно сказать наверняка. Стоит хотябы добавить порядки нагрузок на базу, какой инстанс используете на каких дисках, какая это часть нагрузки на весь сервер и все в таком духе. Кроме того это AWS RDS - всегда можно подкинуть ресурсов и Read Replca.

По структуре данных - всегда можно нормализовать записи и разбить на нормальные таблицы. Если у вас нет какого-то серьезного поиска по этой таблице то вообще можно вынести в DynamoDB.

Опций реально много

Если у вас слишком большая таблица получаются, то вам поможет партицирование https://postgrespro.ru/docs/postgresql/10/ddl-part... Тогда UPDATEs станут быстрее работать, ибо id будет искаться не во всей таблице, а в конкретной секции. Если Postgres будет все-равно задыхаться под кол-во запросов, то придется применить шардирование. Завести еще один или несколько инстансов бд, в одной например будет таблица с матчами из Москвы, а в другой из Краснодара. Как выбрать ключ шардирования(по городу, региону, id, хэшу от чего-то и т.д) только вы можете решить исходя из бизнес логики и объема данных.

Если вы переписываете JSON целиком и не ищете в нем ничего, то смысла выносить в отдельные колонки нет.

Из того что автор описал - у меня возникает архитектурный вопрос. Кто придумал - использовать JSON для данных которые часто обновляются? Это - антипаттерн. Вы какое железо не поставте - у вас будет плохой перформанс.

Вам необходимо все данные которые имеют реляционный (точечный) доступ убрать из JSON. По сути - развалить его на модель EAV или что-то вроде того (Relational Data (RD)). Обновления станут быстрее. А для отчотности - если вам так уж важен JSON - отдельные джобы которые будут переливать данные из RD в JSON или формировать его на лету средствами клиента. В этом случае у вас не будет накладных расходов даже на хранение.