3 ms·

Show HN: Inquery (YC W23) – Real-time events for Postgres

23 points by mitchpatin 4y ago

Hi HN, we're excited to share our open source tool with the community! Inquery is a utility for Postgres that triggers webhooks when rows are inserted, updated, or deleted. It uses database triggers that send low-latency websocket messages to a Go application. This application then calls any configured webhooks with a JSON payload that includes specified values from the database row. Let us know if you have any feedback or questions!

halotrope 4y ago
This is exactly what I was looking for. Can you add it to Supabase please?
- kiwicopple 4y ago
  {disclosure - supabase employee} hopefully this isn't detracting too much from Inquery's product, which looks great, but I thought it's worth flagging - https://supabase.com/docs/guides/database/webhooks https://supabase.com/docs/guides/database/webhooks
  - mritchie712 4y ago
    Yeah, we already use this feature in Supabase, works great!
  - mitchpatin 4y ago
    Not at all detracting - we're big fans of Supabase! We're taking a bit of a different approach by trying to bring tools to existing databases (like those hosted in RDS) as opposed to the full platform approach. We played around with Database Webhooks in Supabase and really liked the experience!
    - kiwicopple 4y ago
      I completely agree with your approach - it's something missing in RDS. Feel free to reach out if there's anything we can help with
tony_landis 4y ago
What are the specific requirements postgres must soppprt? Any extensions or pl language support needed?
- ciminelli 4y ago
  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.
drx 4y ago
Pretty cool! Any plans for a cloud version? If so, what would be the pricing model?
- mitchpatin 4y ago
  Thanks! We've discussed offering a cloud version at some point; however, we're initially focused on the self-hosted version. Regarding the cloud option, we'd likely take a usage-based approach to pricing. Not sure if that would be based on number of events, actions, or some combination of the two. When we do offer this, we'll make sure that the free tier is generous and easy for small projects to use without worrying about paying.
somehelpful 4y ago
Are you using NOTIFY? If so, how do you handle the limit of 8000 bytes?
- ciminelli 4y ago
  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!
  - avinassh 4y ago
    can you elaborate on how this would work?
    - ciminelli 4y ago
      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.
v3ss0n 4y ago
Supabase 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?
- ciminelli 4y ago
  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!

23 points by mitchpatin 4y ago

halotrope 4y ago

This is exactly what I was looking for. Can you add it to Supabase please?

kiwicopple 4y ago
{disclosure - supabase employee} hopefully this isn't detracting too much from Inquery's product, which looks great, but I thought it's worth flagging - https://supabase.com/docs/guides/database/webhooks https://supabase.com/docs/guides/database/webhooks
- mritchie712 4y ago
  Yeah, we already use this feature in Supabase, works great!
- mitchpatin 4y ago
  Not at all detracting - we're big fans of Supabase! We're taking a bit of a different approach by trying to bring tools to existing databases (like those hosted in RDS) as opposed to the full platform approach. We played around with Database Webhooks in Supabase and really liked the experience!
  - kiwicopple 4y ago
    I completely agree with your approach - it's something missing in RDS. Feel free to reach out if there's anything we can help with

tony_landis 4y ago

What are the specific requirements postgres must soppprt? Any extensions or pl language support needed?

ciminelli 4y ago
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.

drx 4y ago

Pretty cool! Any plans for a cloud version? If so, what would be the pricing model?

mitchpatin 4y ago
Thanks! We've discussed offering a cloud version at some point; however, we're initially focused on the self-hosted version. Regarding the cloud option, we'd likely take a usage-based approach to pricing. Not sure if that would be based on number of events, actions, or some combination of the two. When we do offer this, we'll make sure that the free tier is generous and easy for small projects to use without worrying about paying.

somehelpful 4y ago

Are you using NOTIFY? If so, how do you handle the limit of 8000 bytes?

ciminelli 4y ago
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!
- avinassh 4y ago
  can you elaborate on how this would work?
  - ciminelli 4y ago
    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.

v3ss0n 4y ago

Supabase 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?

ciminelli 4y ago
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!