4 ms·

Hasura evaluated Postgres' listen/notify feature to power their subscriptions, but chose polling instead: https://github.com/hasura/graphql-engine/blob/master/

Hasura evaluated Postgres' listen/notify feature to power their subscriptions, but chose polling instead: https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md https://github.com/hasura/graphql-engine/blob/master/archite... > Listen/Notify: Requires instrumenting all tables with triggers, events consumed by consumer (the web-server) might be dropped in case of the consumer restarting or a network disruption. It was substantially non-trivial for them to implement subscriptions that were both robust and efficient using this approach. Many applications need the extra step on top of listen/notify of relaying subscriptions to an untrusted client (e.g., a browser). I'd like to see more DBs bake that feature in, like RethinkDB did.

nicoburns 5y ago
The Superbase (https://github.com/supabase/realtime https://github.com/supabase/realtime) approach is really interesting. It listens to the logical replication stream. Makes a lot of sense to me. Unfortunately our postgres instances hosted on heroku don't expose this, so I've been unable to try it out.
- vaughan 5y ago
  Hasura discusses why they chose polling here (https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#when-do-we-refetch https://github.com/hasura/graphql-engine/blob/master/archite...). > WAL: Reliable stream, but LR slots are expensive which makes horizontal scaling hard, and are often not available on managed database vendors. Heavy write loads can pollute the WAL and will need throttling at the application layer. Would like to hear Supabase's response to this.
  - kiwicopple 5y ago
    Hasura's approach is great and there are just tradeoffs between approaches. Sure, slots (can be) expensive; GCP doesn't offer slots but all the others do as far as I know (and I see that as a GCP issue, not a Supabase issue); a lot of writes can definitely fill the WAL. Stepping back, the main comment I can give is that we each approach problems with a slightly different philosophy. Hasura tackles problems using middleware and Supabase tackles problems using the database. Both are fine. Our approach is important (to us) as we evolve the product. For example, we are adding Row Level Security to our Realtime instance. Because it all sits in the database it's essentially just a Postgres extension, minimizing chatter between a middleware server and the database. Also because it's at the "bottom of the stack", other vendors/integrations can make use of the functionality we provide. (supabase cofounder)

nicoburns 5y ago

The Superbase (https://github.com/supabase/realtime https://github.com/supabase/realtime) approach is really interesting. It listens to the logical replication stream. Makes a lot of sense to me. Unfortunately our postgres instances hosted on heroku don't expose this, so I've been unable to try it out.

vaughan 5y ago
Hasura discusses why they chose polling here (https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#when-do-we-refetch https://github.com/hasura/graphql-engine/blob/master/archite...). > WAL: Reliable stream, but LR slots are expensive which makes horizontal scaling hard, and are often not available on managed database vendors. Heavy write loads can pollute the WAL and will need throttling at the application layer. Would like to hear Supabase's response to this.
- kiwicopple 5y ago
  Hasura's approach is great and there are just tradeoffs between approaches. Sure, slots (can be) expensive; GCP doesn't offer slots but all the others do as far as I know (and I see that as a GCP issue, not a Supabase issue); a lot of writes can definitely fill the WAL. Stepping back, the main comment I can give is that we each approach problems with a slightly different philosophy. Hasura tackles problems using middleware and Supabase tackles problems using the database. Both are fine. Our approach is important (to us) as we evolve the product. For example, we are adding Row Level Security to our Realtime instance. Because it all sits in the database it's essentially just a Postgres extension, minimizing chatter between a middleware server and the database. Also because it's at the "bottom of the stack", other vendors/integrations can make use of the functionality we provide. (supabase cofounder)