Что лучше: больше полей или больше Join?
Куча count - возможно, но не join-ов.
SELECT 
    posts.id, 
    posts.name, 
    count(case when s_vk.social_name = 'vk' then 1 end) as count_vk, 
    count(case when s_vk.social_name = 'tg' then 1 end) as count_tg,
    count(case when s_vk.social_name = 'ok' then 1 end) as count_ok,
    count(case when s_vk.social_name = 'tw' then 1 end) as count_tw
FROM posts
   LEFT JOIN socials as s_vk on s_vk.post_id = posts.id 
GROUP BY posts.id, posts.name
В вашем случае для ускорения не подходит ни то, ни другое.
Нужно вести отдельную таблицу в качестве кеша с аналогичными полями:
 posts_id, 
 count_vk, 
 count_tg,
 count_ok,
 count_tw
При возникновении события клика на соц. сеть - добавлять запись в socials, а также триггером плюсовать значение по полю кеш-таблицы (и предварительно создавать запись в этой таблице по post_id, если не было ранее событий).
Для необходимости сброса кеша нужно сделать хранимую процедуру для его перегенерации на основе данного запроса.
PS:
Еще бы разбить таблицу socials - на справочник соц. сетей:
id - идент. соц сети.
full_name - полное название соц. сети, 
abbrev - аббревиатура, например, ОК, ВК и т.д.
tag_name - тех. название, например, ok, vk и т.д.
... - другие параметры соц. сети

И таблицу для фиксации кликов:
soc_click_events
id - идент. события,
post_id - идент. поста,
social_id - идент. соц. сети,
event_date - дата и время клика,
... - другие параметры клика

PPS:
В итоге, для фиксации событий клика и поддержания структуры базы в нормальной форме вы используйте три таблицы - posts, socials и soc_click_events.
Для решения статистических задач вы делаете отдельные кеш-таблицы и обслуживаете их либо триггерами, либо хранимыми функциями и процедурами, получая статистические данные из первичной структуры.
Больше джоинов - нужно больше индексов и запрос дольше и сложнее будет выполняться из-за необходимости джоинить и обращаться к разным областям диска.

Больше колонок - больше места занимает отдельная запись, больше места занимает вся база, нужно больше индексов, если нужно по этим колонкам фильтроваться. Запрос дольше выполняется из-за необходимости больше данных с диска читать.

+ Учитывай, какой вариант тебе будет поддерживать легче, если нужны будут какие-то изменения.

Нужно смотреть на конкретное железо и статистику, чтобы понять, какой вариант будет эффективнее.

Конкретно в этом случае мне больше нравится вариант, где будет по колонке на каждую соцсеть - так СУБД сможет в один проход и без каких-либо индексов всё посчитать.

А ещё в вашем кейсе можно посмотреть в сторону БД временных рядов.
А ещё можно вообще не фиксировать каждый отдельный клик, а хранить уже в агрегированном виде количество кликов на каждом посте (может быть как дополнение к предыдущим вариантам, чтобы ускорить запросы)