[giraffe_lady]

It's postgres behind a naive rest api. You can implement caching by hand at the db with materialized views or plv8 functions or whatever makes sense there. Or at the api gateway with cloudflare or something I guess but that's not my area so only guesses really.

The realtime stuff can generate a fuckton of writes depending on how you have it set up and what your use is, that's probably the most likely scaling footgun.

[KaoruAoiShiho]

Yes I'm talking about the realtime stuff. I thought that's the reason why people use stuff like supabase. I run chatrooms with hundreds of people in it, for example like this: https://fiction.live/stories/The-Only-Thing-I-Know-for-Real/...

Meteor scaled horribly for that usecase.

[wenbo]

Supabase dev and the maintainer of Supabase Realtime here!

Meteor was before my time (I was doing product when Meteor was all the rage back in the day and never had a chance to explore it as a dev) so can't speak to that but Realtime scales pretty well since it's an Elixir/Phoenix server listening to a Postgres database.

We've recently added Realtime RLS, a more secure version of Realtime, so we need to continue to tune it to make it more performant. I think a couple hundred is doable for now. You should give it a try and give us feedback.

We have a Supabase user who is running the version prior to Realtime RLS, which is more performant at the expense of security, and they have thousands of users chatting concurrently. Just to clarify these chat messages are being saved to a database and then being broadcast to thousands of users.

We're also actively working on Realtime Broadcast which doesn't need to go through the database. Great for ephemeral chat messages and definitely more performant.