This is great. Do you need to be cautious of overloading your Supabase database and impacting performance with heavy use of multiplayer?
I think just being mindful about disk space and CPU usage will be helpful when setting up a database for logical replication because of changes being recorded to WAL files and having Realtime poll the database for changes.
Our initial version of Realtime streams database changes to the server and those get broadcast to clients. However, the only security offered is checking whether or not a JWT is valid when client attempts to connect.
The second and current version of Realtime, which I discussed in this post, checks database role and claims of subscriptions for every database change against RLS policies. This comes with a performance tradeoff as it prioritizes security. We are benchmarking this version in our new Supabase Realtime version and our team will try and optimize performance.
> impacting performance with heavy use of multiplayer
Realtime only needs a single connection to the database, and once a node gets the changes, it'll broadcast them to all other nodes in the cluster which will then be forwarded to all clients. This is highly scalable and nodes can be added in different regions experiencing higher loads. We're going to add in rate limiting to make sure that the cluster remains healthy, but those rate limits can be customized depending on the use case.
It's also worth mentioning that "Presence" and "Channels" don't put any additional load on your database. You can broadcast messages (like the cursor movements in this demo) without it touching your database.
In particular when it comes to the database side you're going to want to limit individual realtime event writes. I suggest write to an append only log table and process the data in batches using a background worker.
If you intend to insert every event one by one and index them various ways and have foreign keys to and from, inserting is going to incur a high cost. This can be mitigated for the most part with temporal partitioning, but even then it might be fine for you use case or analytic case to do background updates over an append only log and keep your appends quite fast.
As for the network traffic and loading of the HTTP front end someone else on the team can maybe chime in on that.
EDIT: Note this is very broad advice for any realtime app and not specific to this product.