This is really useful - well done and thanks for making this available to the community.

Thank you for providing a more general and complete solution for pg_notify. The DX is good. Really like it.

As far as I know it’s been working stably for people. It has a pretty thorough test suite. So overall, it should be fine to use in production.

The method of database notifications that ecto_watch uses should scale quite a ways, but if you have a really large amount of activity or if you have big bursts, you should understand it’s performance characteristics (as with anything).

I have one PR that I hope to be merging soon to protect people from database trigger/function names being too long. Before that is merged, I’d suggest checking out this issue and using the label option if you experience a similar issue on startup.

Can we use this in production?

Not sure that I understand, but the structure that is used is pretty simple. If you add EctoWatch into your application, a Supervisor is created. For every EctoWatch watcher that you add, a GenServer is created which listens for messages from the database.

When the Supervisor is started, it runs these queries for each watcher:

• CREATE OR REPLACE FUNCTION ...
• DROP TRIGGER IF EXISTS ...
• CREATE TRIGGER ...

The trigger calls the function which sends a notification to your application/the watcher GenServer.

And then each GenServer does a Phoenix.PubSub.broadcast for each message from the database so that you can get application updates (as described in the README)

If that’s not clear I’m happy to answer other questions.