worker VS walex

Big fan of Graphile Worker to handle this job. https://github.com/graphile/worker

I do enjoy using https://github.com/graphile/worker for my postgresql queuing needs. Very scalable, the next release 0.14 even more so, and easy to use.

On the same subject (job queue based on PostgreSQL), I'm successfully using the https://github.com/graphile/worker/ (NodeJS) project in production.

Jobs are written in Javascript.

Postgres is used both as a store of state for Runs/Tasks and for the Job queue (we use Graphile Worker).

Having now built V5's unified plugins and presets system, I'm extremely pleased with it! I'm so happy, in fact, that I'm looking forward to integrating it with Graphile's other tools such as Graphile Worker (our Postgres-backed job queue) and Graphile Migrate (a lightweight SQL-based migration framework that focuses on DX) once V5 is out and stable.

Another good library for this is Graphile Worker:

https://github.com/graphile/worker

Uses both listen notify and advisory locks so it is using all the right features. And you can enqueue a job from sql and plpgsql triggers. Nice!

Worker is in Node js.

https://github.com/graphile/worker

See also graphile-worker: https://github.com/graphile/worker (lower latency than pg-boss because it uses LISTEN/NOTIFY)

graphile-worker - High performance Node.js/PostgreSQL job queue (also suitable for getting jobs generated by PostgreSQL triggers/functions out into a different work queue)

We're currently keeping it as simple as possible. We just use a table and this query that runs every second: `DELETE FROM job_queue RETURNING type, info;`. Works great and reliably so far. I think our current volume is on the order of 100-1000 req/sec.

We'll likely switch to graphile-worker when we need more performance, but we're all about avoiding premature optimization. That library has been benchmarked to handle 10k req/sec: https://github.com/graphile/worker#performance

Anybody using graphile-worker[1] in production/heavy load? It looks awesome, and I coded up some simple prototype tasks (email, sms, etc), but question how it truly scales. They claim horizontal scaling is trivial.

> it achieves an average latency from triggering a job in one process to executing it in another of under 3ms, and a 12-core database server can process around 10,000 jobs per second.

[1] https://github.com/graphile/worker

Great post, I really like the approach of adding additional context for WAL CDC.

I use both the trigger + audit table in my sass (for user-facing activity feeds) and subscribe to CDC WAL changes for dealing with callback -like logic (i.e., send registration email, clear cache).

I'm not a fan of pg_notify due to requirement of adding triggers (performance penalty) and the 8k character limit per column (you will lose data is it will splice off anything larger than that).

Application-level tracking or callbacks makes the stack dependent on the application for data integrity, I'd rather the database be the source of truth on all things data.

I'm the maintainer of an open-source CDC library for PostgreSQL called WalEx. It's lighter weight and much simpler to operate than Debezium:

https://github.com/cpursley/walex

For something turn-key, Bemi looks like a really good option!

The WAL CDC approach: https://github.com/cpursley/walex?tab=readme-ov-file#publica...

CREATE PUBLICATION news_item FOR TABLE news WHERE (topic IS "AAPL");

What do you mean testing with processes?

I won't suggest these are the best written tests, but I test various processes, supervisors, etc like this:

https://github.com/cpursley/walex/blob/master/test/walex/sup...

WalEx instead of pub/sub (listen/subscribe): https://github.com/cpursley/walex

Supavisor connection pooler: https://github.com/supabase/supavisor

Yep, I should add that. One of the libraries in my list is WalEx: https://github.com/cpursley/walex/issues

It subscribes to the Postgres WAL and let you do the same sort of thing you can do with listen/notify, but without the drawbacks like need for triggers or character limits.

You don’t send the entire WAL, just what you subscribe to - and you can even filter via SQL: https://github.com/cpursley/walex?tab=readme-ov-file#publica...

Good stuff, I'm a little obsessed with the Postgres replication and WAL.

If you're an Elixir user, you might find my library for subscribing to Postgres WAL events useful: https://github.com/cpursley/walex

It's a lot easier to operate than the typical debezium setup (which is what I think Airbyte uses behind the scenes).

What we do is much if the business logic in Postgres. But then there’s all the other stuff like external integrations, etc.

We handled that by having an Even system built on the Postgres WAL that we use like a callback system.

I put together a little library in Elixir (that originally started out as forked Supabase realtime) for this:

https://github.com/cpursley/walex

Recently added the ability to configure WalEx to forward events to webhooks or EventRelay (so you don’t need to know Elixir).

If you're using Elixir, check out https://github.com/cpursley/walex

I've actually been thinking about turning this idea into a product where you can just point it at your postgres database and select the tables you want to listen to (with filters, like you describe). And have that forwarded to a webhook (with possibility of other protocols).

I'd love to hear folks thoughts on that (and if it would be something people would pay for).