realtime subscription tradeoffs

[GaryAustin1]

I don't find much information on "cost" (resources on server/database) of a "subscription".
Let's say I have 10000 users, each joining 5 low message count chatrooms (basically connection is idle almost all the time) and each chatroom has 5 users in it.
Is it better to have 5 subscriptions open per logged in user for each of their chatrooms to detect a new message, or to have a SINGLE chat status subscription on a status table with a row per user which has an array that gets updated by a trigger if a message is generated in a chatroom. Basically 5 extra data base writes for each user's status row versus 5 subscriptions.
If subscription "cost" is low, especially with low number of messages) then obviously an easier implementation.
Thoughts?

[abc3]

It is pretty cheap to use subscriptions. Phoenix framework (inside Realtime) makes a new Elixir process on each subscription and adds a record in two tables in in-memory KV storage. The only thing that updates could be copied to a few subscription processes, which will increase RAM usage. But it can be an issue only on large datasets.