Alex Wells

у тебя роут в api, который не держит сессии

Падавана в Академии не учат припадать к источнику мудрости в затруднительных ситациях?

Первый вариант не годится.
Второй случай - не совсем понятно, зачем вам два форыча - первые посты вы захотите вывести при отображении списка топиков (как я понимаю), второй раз выведите все посты, связанные с топиком, но тут main 1|0 уже не играет роли. Т.е. на одну задачу вам нужно один раз вытягивать посты, просто по разным критериям.
Основной пост для топика можно определять по дате создания (первый при сортировке по дате) и кешировать (чтобы не расходовать ресурсы на поиск первого поста каждый раз), чтобы не использовать доп. колонку для флага.
На уровне бизнес-логики (php-кода) надо запретить удалять первый пост.

https://laravel.com/docs/6.x/packages#package-discovery

Я бы не использовал. По причини боли при мажорных обновлениях. А они бывают не редко.
1. Нужно переиндексировать все индексы в актуальную версию перед обновлением на следующую. (reindex api спасает, но все равно не приятно делать на горячей бд)
2. В мажорных обновлениях часто меняют типизацию. В NoSQL с нестрогой типизацией это всегда неожиданно.
3. Бекапы старых версий не развернуть на новых. Бекап с возрастом в пару лет становится тыквой прям по определению.
4. Проблемы производительности если хранить много лишних данных в индексах. (Кушает память на весь документ, а не только на нужные поля - часто срабатывает gc, который кушает проц. Уменьшается эффективность кеша)
5. И главное. Он асинхронный. т.е запись в выдаче появляется не сразу. Это иногда приводит к сложностям в коде

Elasticsearch не является базой данных, а просто поисковым индексом. Использовать его как БД нельзя ни в коем случае.
- никакой консистентности
- никакого ACID
- управление доступом только в коммерческой версии за много денег
- чтобы изменить тип данных в документе надо изменить маппинг только через полное пересоздание индекса
- лимит по выдаче данных. Проблемы начинаются уже после первой тысячи в поиске ибо рассчитан он изначально на выдачу 1-3 результатов
- эластик ест столько памяти сколько есть на виртуалке. Дашь ей 2 Tb RAM и будь уверен - он займет все

Замечательный пример того, как не нужно делать. Все можно и нужно выбрать одним запросом. Про индексы не говорю, для единичных выборок они нужны, для полной выборки - скорее нет.
Как минимум стоит открыть клиент какой-нибудь и пописать там sql-запросы, делающие нужные вам выборки. Посмотреть планы выполнения, там уже решать, что требует оптимизации.

Смотреть где узкое место.
бд долго отдает? Создавать индексы.
Или может у вас вместо одного-двух запросов 1200? Тогда разбираться с join и оптимизировать запросы.

Ни в коем случае.
Твоя база данных не зря названа реляционной, то есть связанной. Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"

И не надо слушать советчиков из соседних ответов.
Увы, поколение милленниалов не умеет воспринимать письменный текст, и реагирует в лучшем случае на пару ключевых слов в вопросе, не воспринимая корнтекст. Который, чтобы было понятно, звучит так: Нашел у папы в сарае заряженнвую двустволку. Прикладом очень удобно орехи колоть. Это удобнее потому что из щипцов орехи вываливаются. Нормально ли колоть орехи заряженным ружьем?

Сериализованные данные стоит хранить в бд только в очень крайнем случае.
На данном этапе вообще забудь про такую возможность и учись работать с БД правильно.