pgflow
Pooling mechanism, pricing and triggers #31
|
Beginner question, do you know how supabase pricing is affected by a continuously running worker? could we potentially migrate to a pg level trigger? |
Replies: 2 comments 2 replies
|
Hey @piccinnigius! As far as I understand the pricing, they only bill for the invocations (requests) There is also another factor - the data coming out of the database But just polling and returning nothing is using low bandwidth. It mostly depends on how big payloads and how often you will retrieve from the queue. There is more info on the pricing page: Pricing & Fees | Supabase I will ask on Supabase Slack to confirm it with the devs. PS I will add this info to the docs - you were not the first one to ask :-) |
|
Perfect! Thanks again for your committment and for the detailed answer! I manage paypoad size simply by passing the row id of the task to do :) |
|
Sure thing, glad it helps. I'm closing this issue, but if you have any questions or you'll find something that does not work properly please hit me up - I'm working full time on pgflow and I'm happy to help. |
|
FYI @piccinnigius I updated docs website with new FAQ section https://www.pgflow.dev/edge-worker/faq/ |
Hey @piccinnigius!
Thank you for your interest in Edge Worker and pgflow.
As far as I understand the pricing, they only bill for the invocations (requests)
There is also another factor - the data coming out of the database
But just polling and returning nothing is using low bandwidth. It mostly depends on how big payloads and how often you will retrieve from the queue.
There is more info on the pricing page: Pricing & Fees | Supabase
I will ask on Supabase Slack to confirm it with the devs.
PS I will add this info to the docs - you were not the first one to ask :-)