Are you using NOTIFY? If so, how do you handle the limit of 8000 bytes?
Yes and great question, right now we are limited to 8000 bytes but are working on an update to handle large payloads via chunking—stay tuned!
Show HN: Inquery (YC W23) – Real-time events for Postgres
11–16 of 16 posts
Re: Show HN: Inquery (YC W23) – Real-time events for Postgres
#12What are the specific requirements postgres must soppprt? Any extensions or pl language support needed?
No extensions are required since we're using LISTEN/NOTIFY in the triggers! We haven't tested full backwards compatibility with older versions but are planning on doing that soon.
Re: Show HN: Inquery (YC W23) – Real-time events for Postgres
#13Supabase said 8k payload limit of listen/ notify is deal breaker for them so they had to start own websocket based realtime engine by watching oplog.
How would you handle that?
Re: Show HN: Inquery (YC W23) – Real-time events for Postgres
#14Re: Show HN: Inquery (YC W23) – Real-time events for Postgres
#15Supabase said 8k payload limit of listen/ notify is deal breaker for them so they had to start own websocket based realtime engine by watching oplog. How would you handle that?
We're working on and looking into a few different solutions right now:
1. Split the payload into chunks of 8k bytes and send them as separate messages to the server (in progress, will be released in the next few days).
2. Use a new table as an event queue where the trigger will write data and our server will consume it. We do want to incorporate an event queue soon so this approach would solve for that as long as users are ok with the system writing to a new table.
3. Use one of the Postgres logs to stream events instead of LISTEN/NOTIFY.
Let me know if you have thoughts on any of these approaches!
Re: Show HN: Inquery (YC W23) – Real-time events for Postgres
#16Earlier quoted context omitted.
Yes and great question, right now we are limited to 8000 bytes but are working on an update to handle large payloads via chunking—stay tuned!
can you elaborate on how this would work?
The trigger will break the message out into chunks of <8k bytes and send them as separate messages with a unique ID and then an EOF once the message is complete. Planning on releasing this change in the next few days.